What it is
Every plugin declares amanifest of type PluginManifest. It is not human documentation — it is structured metadata the LLM reads. The runtime uses it three ways:
- The Tier-1 prompt block — the “Available Capabilities” list rendered for
alwaysplugins on every turn. list_capabilities— the meta-tool the agent calls to enumerate what it can load.load_capability— the meta-tool that returns a manifest in full when the agent activates a plugin mid-conversation.
What each field is for
Full schema table and validation rules live at Manifest schema reference.
Where the agent sees it
Tier-1 plugins pay token cost on every turn forever — and not just the summary: each entry also renderswhenToUse, whenNotToUse, and the first example as sub-bullets, so manifest length is prompt length. on-demand plugins cost nothing in the prompt until the agent loads them. silent plugins are never listed in Tier-1 and can’t be loaded through the meta-tools (note: a silent plugin’s tools, if it ships any, are still bound and callable — silent is not a security boundary).
Writing a good manifest
- Be specific in
whenToUse. “Weather questions” is too vague. “User asks about current weather, temperature, precipitation, or wind in any city” is precise. - Use
whenNotToUseto disambiguate when your plugin conceptually overlaps with another (Firecrawl vs Sandbox vs Domain Indexer is the canonical case). - Examples should cover the typical patterns, not just the obvious one.
- Keep
tagslowercase. They’re for search ranking, not display. - Pick
visibilitydeliberately. Default toon-demand; promote toalwaysonly when the agent needs the plugin on nearly every turn.
Read next
Write a plugin
Where the manifest lives in code.
Manifest schema reference
Exact field types and constraints.
PluginManifest.