What a plugin bundles
A plugin is the heaviest packaging unit in Antigravity's customization stack: a versioned bundle defined by a plugin.json manifest that can combine up to five primitives — skills, MCP servers, custom agents and subagents, rules, and lifecycle hooks — into one unit that installs, updates and toggles together. Where a skill is a playbook and a rule is a constraint, a plugin is a product: versioned, namespaced, and meant to be shared.
That makes plugins the right unit for "wire my agent into a whole system" — a Jira plugin brings the MCP server plus the skills that know how to use it plus the subagent that runs ticket triage in the background. It is also the most trust-sensitive unit: installing a plugin grants every capability it bundles, so a plugin is the thing to review most carefully before it lands.
Three install paths
- Marketplace —
agy plugin install <name>pulls from the officialantigravity-plugins-officialmarketplace, which requires an activeagysign-in. Marketplace entries are the verified tier: partner-built and Google-built plugins reviewed before listing. - GitHub URL —
agy plugin install https://github.com/<owner>/<repo>installs straight from a repository. This is how most community plugins ship today; the repo is the package. - Local directory — for development or private bundles; the plugin must still carry a valid
plugin.json.
How to evaluate a plugin
- Read
plugin.jsonfirst. The manifest lists every bundled primitive — a plugin that only needs an MCP server but also ships lifecycle hooks deserves a second look. - Vendor plugins are product plugins. The marketplace launch wave (Atlassian, Canva, CrowdStrike, Databricks, Google Cloud's Data Agent Kit) wires Antigravity into SaaS systems; each brings the vendor's MCP endpoint plus skills tuned to it. The install is one line; the account requirements live on the vendor's side.
- A plugin is not the only packaging option. If you only need the MCP server, configuring
mcp_config.jsondirectly is lighter. If you only need the skill, aSKILL.mdfolder is lighter. Plugins earn their complexity when two or more primitives must move together — and they earn their trust cost only when the vendor behind them is one you'd grant that access anyway.
What we verify
Each entry records which install path the plugin actually ships (marketplace name, GitHub repo, or both), what its manifest bundles, and any account or sign-in prerequisite the install surface doesn't mention — verified against the repository or the vendor's own listing, not third-party coverage.
Treat each plugin like a dependency — version-pinned, reviewed, and removable without residue.