# google-agent-plugins-packaging-skills-mcp-2026-08-06

## Veille

Announcement from **Google** on **August 6, 2026**: Google joins as **Core Maintainer** the **Agent Plugins 1.0.0** specification, an open, *vendor-neutral* packaging format for distributing **Agent Skills** and **MCP servers** together. The specification was published by a **TSC** whose Core Maintainers come from **Amazon, Cursor, Microsoft, OpenAI, and Vercel**; Google joins them, represented by **Kevin Hou** (Senior Staff Engineer, Google DeepMind). The two packaged building blocks — Agent Skills and MCP — originate from **Anthropic**, which does not appear on this list of maintainers. **The diagnosis** fits in one sentence: *"The core problem isn't the components. It's the manifest."* A skill is portable, an MCP server is portable; the box they go in is not, and every client had to invent it for itself — hence the forks, the copies of identical components, and their drift. **The format** fits in one constraint: *"A plugin is a directory. That's the whole idea, and the restraint is the point."* A `plugin.json` with two useful lines (`$schema` and `name`), skills in `skills/` in the Agent Skills format, servers declared in `mcp.json` with an **explicit `type` on each entry** (stdio, Streamable HTTP, or the legacy HTTP+SSE) — no more transport guessed from the shape of the config object. The strength of the design lies in what the manifest **cannot** do: neither relocate components nor declare them inline, so there is no discovery path to configure and no precedence order to learn. Operational corollary: components **fail independently** — an `mcp.json` server that fails to start does not take down the plugin's skills, the client skips the entry, keeps going, and reports the failure. The accepted escape hatch is the **reverse-domain** directory (`com.example.client/`), an extension space owned entirely by one client (hooks, agents, commands) that other clients ignore: *"the portable core stays small because the non-portable parts have somewhere legitimate to go."* A section is dedicated to cases where the format is not warranted — *"Not every skill should be a Plugin"*: a single MCP server to a single client, `mcp.json` suffices; a single skill needs no plugin. What v1 explicitly excludes, under *future considerations*: **no installation mechanism, no distribution protocol, no permissions model, no sandboxing requirement, no trust or provenance verification, no UX**. All of this fits into an independently adoptable four-layer stack — **find** (Agentic Resource Discovery), **describe** (AI Catalog, which would register the `application/agent-plugins+json` type), **package** (Agent Plugins), **run** (MCP + Agent Skills). Two Google products already ship: **Agents CLI** and **Data Agent Kit** (BigQuery, Spanner, Cloud SQL).

## Titre Article

Agent Plugins package your skills, tools, and more

## Date

2026-08-06

## URL

https://developers.googleblog.com/agent-plugins-package-your-skills-tools-and-more/

## Keywords

Agent Plugins, Agent Plugins 1.0.0, open specification, vendor-neutral, Core Maintainer, TSC, specification governance, packaging, packaging, plugin, plugin.json, manifest, mcp.json, SKILL.md, skills/, scripts/, references/, Agent Skills, Model Context Protocol, MCP, MCP server, explicit transport, stdio, Streamable HTTP, HTTP+SSE, portability, interoperability, package fork, copy drift, directory structure, fixed location, precedence order, discovery path, independent failure, component isolation, reverse domain, extension namespace, com.example.client, escape hatch, portable core, Agentic Resource Discovery, ARD, resource discovery, AI Catalog, application/agent-plugins+json, agent card, discovery layer, execution layer, execution contract, independent adoption, agent-plugins.org, Agents CLI, Data Agent Kit, Google Data Cloud, BigQuery, Spanner, Cloud SQL, Antigravity, Gemini CLI, Claude Code, Cursor, Amazon, Microsoft, OpenAI, Vercel, Anthropic, Kevin Hou, Haoyu Wang, Alan Blount, Google DeepMind, absence of provenance verification, permissions model, sandbox, sandboxing, supply chain, unglamorous infrastructure, restraint, reinvention

## Authors

Trois signataires, répartis sur trois entités Google :

- **Kevin Hou** — Senior Staff Engineer, **Google DeepMind**. Il représente Google au **TSC** de la spécification ; la fonction de mainteneur est nominative, non institutionnelle.
- **Haoyu Wang** — Staff Software Engineer, **Google Cloud Data**, côté Data Agent Kit.
- **Alan Blount** — Technical Product Manager, **Google Cloud AI**.

Publié le **6 août 2026**. Billet d'ingénierie signé, écrit à la première personne du pluriel pour Google, mais portant sur une spécification qui n'est pas de Google — ce dont la rhétorique tire parti : *« Those skills were already distributable. Now they're distributable in a format that isn't ours alone. »*

## Ton

**Profile**: technical announcement post, **engineering** register, argued through restraint rather than ambition. No product superlatives, no performance figures, no transformation promises. Audience: authors of skills and MCP servers who distribute to multiple clients.

**Style**: structured in **six movements** — the lived problem (you're shipping to a second client) → what a plugin actually is → when not to make one → what the spec excludes → the stack it fits into → what ships. Three traits:

1. **The second-person opening, set on a work scene.** *"You wrote a skill. You wrote a script or an MCP server to go with your skill."* No market overview: a friction, recognizable, then the diagnosis in one line — *"The core problem isn't the components. It's the manifest."*
2. **Argumentation by subtraction.** The text devotes more space to **what the format doesn't do** than to what it does: what `plugin.json` **cannot** do (relocate, declare inline), what v1 **excludes** (installation, distribution, permissions, sandbox, provenance, UX), and a whole section on **when not to use it**. *"The restraint is the point."*
3. **The anti-heroic closing line.** *"Packaging is unglamorous infrastructure, and unglamorous infrastructure is exactly the kind of thing that should be shared rather than reinvented five times."* An unusual register for a platform post: the selling point is that the object is not interesting.

**Marker phrases**: *"The core problem isn't the components. It's the manifest."*, *"A plugin is a directory. That's the whole idea, and the restraint is the point."*, *"Independent components fail independently."*, *"the portable core stays small because the non-portable parts have somewhere legitimate to go"*, *"Not every skill should be a Plugin"*, *"a format that isn't ours alone"*, *"unglamorous infrastructure"*.

**Epistemic stance**: **descriptive and bounded**. The text claims no measured adoption, compares to no competitor, and lists its own blind spots in a dedicated section rather than a footnote. What it also does not do: discuss the security of the distribution it makes easier.

## Pense-betes

- **Read the announcement through governance before technology.** The format matters less than **who holds it**: a TSC of Core Maintainers from **Amazon, Cursor, Microsoft, OpenAI, Vercel**, joined by **Google**. Six competing players on a packaging layer. **Anthropic is not on the list of maintainers** — even though **Agent Skills** and **MCP**, the two packaged formats, come from it. Do not overinterpret (absence from this list is not exclusion, and the post says nothing about the rest of the governance), but **the fact stands**: the layer that makes Anthropic's formats distributable is being standardized elsewhere. Compare with [[openai-agentic-ai-foundation-linux-2025-12-09]] on the open standardization of the agent layer, and [[janakiram-agent-platform-portability-contract-2026-07-20]] on the portability contract between platforms.
- **The diagnosis, reusable as-is**: ***"The core problem isn't the components. It's the manifest."*** A skill is portable, an MCP server is portable; **the box is not**, and every client had to invent it. Symptoms to recognize in your own distribution: one fork per client, two copies of identical components, and the drift that follows.
- **The format in five lines, worth remembering**: ``` reports-plugin/ ├── plugin.json          # $schema + name: two useful lines ├── skills/summarize/    # SKILL.md, scripts/, references/ (Agent Skills spec) ├── mcp.json             # an explicit `type` on each entry └── com.example.client/  # proprietary extension space, ignored by others ``` → The explicit `type` kills a real ambiguity: **no more transport guessed from the shape of the config object** (stdio / Streamable HTTP / legacy HTTP+SSE).
- **The best design idea: what the manifest cannot do.** `plugin.json` **can neither relocate a component nor declare it inline**. Consequences: **no discovery path to configure**, **no precedence order to learn**. This is an engineering choice transferable well beyond agent plugins — *any expressiveness left to a configuration file becomes a surface of divergence between implementations*. Here, the format is made portable by **removing** power from it.
- **The resulting operational rule**: ***"Independent components fail independently."*** An `mcp.json` server that fails to start **does not take the plugin's skills down with it** — the client skips the entry, keeps loading, and reports the failure. Worth verifying explicitly in any client that claims to implement the spec: it's the kind of guarantee that turns out to be missing in production.
- **The reverse-domain escape hatch — and its downside.** `com.example.client/` is an **extension space** owned by a single client (hooks, agents, commands), ignored by others. Stated argument: *the portable core stays small because the non-portable parts have a legitimate place to go*. **The same mechanism is the vector through which portability can hollow out**: if usage value gradually migrates into the proprietary directories, the plugin remains formally portable while becoming practically single-client. **Metric to watch on your own plugins**: what share of functionality lives outside the portable core.
- **The section rarely seen in a platform post** — *"Not every skill should be a Plugin"*: a single MCP server to a single client → **`mcp.json` alone remains the simplest answer**; a single skill → **no plugin needed**. The format is only justified for **components that belong together and must travel together**. A criterion to apply before converting an existing repository.
- **What v1 excludes, to be read as a list of risks you must cover yourself**: **no installation mechanism, no distribution protocol, no permissions model, no sandboxing requirement, no trust or provenance verification, no UX**. The post justifies this (the obligations of an IDE, a CLI, and an enterprise platform genuinely differ) and owns it under *future considerations*. **Translation for whoever deploys**: a standard format that makes it easier to circulate **executable code** (skills with `scripts/`, MCP servers) **without** a provenance layer shifts the supply-chain burden entirely onto the client and onto you. Worth examining alongside [[valente-zalewski-beyond-zero-enterprise-security-ai-era-2026-07-20]] and [[sfeir-anthropic-sdlc-ai-native-securise-2026-07-26]]: execution perimeter, network egress restriction, third-party skill review.
- **The four-layer stack — table worth reusing**: | Job | Layer | What it does | |---|---|---| | **Find** | Agentic Resource Discovery | open protocol: "what exists for this task?" — already treats the plugin as a first-class resource, **before** invocation | | **Describe** | AI Catalog | catalog format indexed by ARD; proposed registration of the `application/agent-plugins+json` type | | **Package** | Agent Plugins | a directory, fixed locations | | **Run** | MCP + Agent Skills | the execution contracts, already portable | → **Each layer is independently adoptable**: publishing a plugin without a catalog entry, cataloging a resource that isn't a plugin, running skills without a plugin. *"Adopting one never obligates you to the next."* A promise worth checking against the facts. **Graph convention** (cf. girard-acp-deux-protocoles-un-sigle-2026-08-02): **never create an `ARD` entity** — the canonical entity is **Agentic Resource Discovery**, "ARD" is only an alias.
- **What is shipping today**: **Agents CLI** (Google skills for agent building, evaluation, deployment, observability, publishing — usable from **Antigravity, Gemini CLI, Claude Code, or Cursor**) and **Data Agent Kit** (BigQuery, Spanner, Cloud SQL). Note the phrasing: *"Those skills were already distributable. Now they're distributable in a format that isn't ours alone."* — **the novelty is not the capability, it's the neutrality of the container.**
- **Meta / to link**: on the packaged building block, agent-skills-anthropic-2025-10-16 and claude-skills-document-manipulation-willison-2025-10-10; on the client↔agent layer stacking above it, agentclientprotocol-introduction-2026-08-02; on skill discovery and directories in practice, graphify-net-annuaire-ia-coding-2026-08-06 and skill-shamsi-graphify-2026-08-06; on competing instruction formats, gao-vercel-agents-md-outperforms-skills-evals-2026-01-27 (Vercel, also a Core Maintainer here).

## RésuméDe400mots

Engineering post from **Google** on **August 6, 2026** announcing that the company joins as **Core Maintainer** the **Agent Plugins 1.0.0** specification — an open, *vendor-neutral* packaging format for distributing **Agent Skills** and **MCP servers** together.

**The governance fact first.** The specification was published by a TSC of Core Maintainers from **Amazon, Cursor, Microsoft, OpenAI, and Vercel**. Google joins them, represented by name through **Kevin Hou** (Google DeepMind). Six competitors agree on a packaging layer. **Anthropic does not appear on the list of maintainers**, even though the two packaged building blocks come from it.

**The diagnosis.** A skill is portable, an MCP server is portable — *"The core problem isn't the components. It's the manifest."* What has never been portable is the box: directory layout, manifest metadata, the shape of the MCP configuration, and transport inference differ from one client to another. People fork, maintain two copies of identical components, and they drift apart.

**The format.** *"A plugin is a directory. That's the whole idea, and the restraint is the point."* A `plugin.json` reduced to `$schema` and `name`; skills in `skills/`, in the Agent Skills format; servers in `mcp.json`, **with an explicit `type`** on each entry (stdio, Streamable HTTP, legacy HTTP+SSE). The strength of the design lies in what the manifest **cannot** do: neither relocate a component nor declare it inline. So there is no discovery path to configure, no precedence order to learn. Corollary: **components fail independently** — a server that fails to start does not take the skills down with it. A **reverse-domain** directory (`com.example.client/`) serves as a proprietary extension space, ignored by other clients: the portable core stays small because the non-portable parts have somewhere to go.

**The limits, openly stated.** A whole section explains **when not to make a plugin** (a single MCP server, a single skill: unnecessary). Another lists what v1 excludes: **installation, distribution, permissions, sandboxing, trust and provenance verification, UX**. Justification: the obligations of an IDE, a CLI, and an enterprise platform genuinely differ.

**The stack.** Find (**Agentic Resource Discovery**), describe (**AI Catalog**), package (**Agent Plugins**), run (**MCP + Agent Skills**) — each layer independently adoptable.

**Shipping today**: **Agents CLI** (usable from Antigravity, Gemini CLI, Claude Code, or Cursor) and **Data Agent Kit** (BigQuery, Spanner, Cloud SQL). *"Those skills were already distributable. Now they're distributable in a format that isn't ours alone."* Closing line: *"Packaging is unglamorous infrastructure,"* and that is precisely what should be shared rather than reinvented five times.

## GrapheDeConnaissance

- Google —collabore_avec→ Agent Plugins (TECHNOLOGIE, 0.97)
- Kevin Hou —travaille_chez→ Google DeepMind (ORGANISATION, 0.96)
- Kevin Hou —dirige→ la représentation de Google au comité de pilotage technique d'Agent Plugins (AFFIRMATION, 0.93)
- Agent Plugins —permet→ d'empaqueter des Agent Skills et des serveurs MCP dans un plugin portable d'un client à l'autre (AFFIRMATION, 0.97)
- Agent Plugins —utilise→ Agent Skills (TECHNOLOGIE, 0.96)
- Agent Plugins —utilise→ Model Context Protocol (TECHNOLOGIE, 0.96)
- Amazon —publie→ Agent Plugins (TECHNOLOGIE, 0.9)
- Microsoft —publie→ Agent Plugins (TECHNOLOGIE, 0.9)
- OpenAI —publie→ Agent Plugins (TECHNOLOGIE, 0.9)
- Vercel —publie→ Agent Plugins (TECHNOLOGIE, 0.9)
- Cursor —publie→ Agent Plugins (TECHNOLOGIE, 0.9)
- Google —affirme_que→ le problème de portabilité ne vient pas des composants mais du manifeste qui les emballe (CITATION, 0.96)
- Agent Plugins —résout→ la duplication et la dérive des packages forkés pour chaque client (AFFIRMATION, 0.94)
- Agent Plugins —utilise→ un répertoire à emplacements fixes plutôt qu'un manifeste expressif : plugin.json ne peut ni relocaliser ni déclarer les composants en ligne (AFFIRMATION, 0.95)
- Agent Plugins —réduit→ la surface de divergence entre implémentations, en supprimant les chemins de découverte configurables et les ordres de précédence (AFFIRMATION, 0.91)
- Agent Plugins —permet→ l'échec indépendant des composants : un serveur mcp.json qui ne démarre pas n'emporte pas les skills du plugin (AFFIRMATION, 0.95)
- espace d'extension en domaine inversé —permet→ à un client d'ajouter ses fonctionnalités propriétaires sans casser la portabilité du cœur (AFFIRMATION, 0.93)
- espace d'extension en domaine inversé —s_oppose_à→ la portabilité réelle d'un plugin, si la valeur d'usage migre vers les répertoires propriétaires (AFFIRMATION, 0.82)
- Google —recommande→ de ne pas faire de plugin pour un seul serveur MCP ni pour une seule skill : le format vaut pour des composants qui doivent voyager ensemble (AFFIRMATION, 0.95)
- Agent Plugins —s_oppose_à→ la prise en charge de l'installation, de la distribution, des permissions, du bac à sable, de la vérification de provenance et de l'expérience utilisateur (AFFIRMATION, 0.96)
- Agentic Resource Discovery —permet→ à un client de demander quelles ressources existent pour une tâche, avant toute invocation (AFFIRMATION, 0.93)
- Agentic Resource Discovery —est_instance_de→ couche de découverte de la pile agentique (CONCEPT, 0.9)
- AI Catalog —s_applique_à→ la description indexable des ressources agentiques, dont les plugins via le type application/agent-plugins+json (AFFIRMATION, 0.9)
- Agentic Resource Discovery —utilise→ AI Catalog (TECHNOLOGIE, 0.89)
- Agents CLI —utilise→ Agent Plugins (TECHNOLOGIE, 0.95)
- Data Agent Kit —utilise→ Agent Plugins (TECHNOLOGIE, 0.95)
- Data Agent Kit —s_applique_à→ la gestion des actifs de données Google Data Cloud (BigQuery, Spanner, Cloud SQL) depuis un agent de codage (AFFIRMATION, 0.93)
- Agents CLI —s_applique_à→ Antigravity, Gemini CLI, Claude Code et Cursor (AFFIRMATION, 0.92)
- Google —affirme_que→ l'empaquetage est une infrastructure ingrate, qui doit être partagée plutôt que réinventée cinq fois (CITATION, 0.94)

---
Canonical: https://www.thekb.eu/en/fiches/google-agent-plugins-packaging-skills-mcp-2026-08-06/