Publish a prompt library for your org
A prompt is a reusable, named, versioned message template your agent fetches by name. Publish your best ones to a team or organization catalogue, and agents that use them pull the same vetted prompts — no copy-pasting instructions between people, no drift as each person edits their own copy. This is Share a toolset with your team focused on prompts, with the two things prompts add: arguments and versioning.
Why a shared prompt library
- One canonical version. Every agent that uses
code-revieworsummarize-ticketpulls the same prompt. Improve it once, and those agents get the improvement. - Reusable through arguments. Parameterize a prompt once —
{{language}},{{audience}}— and each caller fills in the values when they fetch it. - Safe to evolve. Every edit is a new version, so you can refine a shared prompt over time and roll back if a change doesn't land.
Names tell you where a prompt lives
On the MCP surface, prompt names are namespaced by ownership so identically-named prompts never shadow each other:
| Owner | Name on MCP |
|---|---|
| Your personal-in-org prompts | me/{name} |
| Team-owned prompts | {team}/{name} |
| Organization catalogue | {name} (unprefixed) |
So code-review names the organization-catalogue prompt, while growth/code-review names the Growth team's version — distinct names, neither overwriting the other.
The workflow
- Draft a prompt — in the dashboard, or let an agent create it in a personal or team space with
create_prompt. - Parameterize it with arguments: declare each
{{name}}and reference it in the content. Content and arguments must agree, which keeps the template self-consistent for everyone who reuses it. - Refine it from real use. When it underperforms in a session, improve it on the spot — see Optimize a prompt from a session. Each update records a new version.
- Promote it to the team or organization catalogue when it is ready for shared use. Promotion into the organization catalogue is a deliberate dashboard action.
Versioning keeps the library trustworthy
Every customer prompt in your library keeps a history of versions; the latest is the one served by prompts/get. Each plan sets how many versions a prompt retains, and when that limit is reached you choose whether a new version is rejected or the oldest is dropped. Restoring an older version brings back the arguments it had, too — so evolving a shared prompt never means losing the one that worked. See Prompts → Versioning.
How members consume it
A member connects with an organization credential. If that credential has access to the prompts surface, their agent discovers the prompts made available to it:
prompts/list— the prompts that credential can see, named by space.prompts/get— fetch one by name, supplying any declared arguments; the server returns the content with each{{name}}filled in.
The customer portion of each list is computed per credential from org-wide prompts and prompts made available through that credential's team bindings. If the credential acts on behalf of the member, the list can also include that member's personal-in-org prompts. The access model can narrow the result further; to scope a specific key, see Scope an agent to least privilege.
Native prompt lists also include platform prompts under apistash/ when their platform allowlist, effective Prompts capability, and Prompt policy admit them. Their content is maintained by apistash.