Add optional privacyPolicyUrl and termsOfServiceUrl to plugin metadata #92

Summary

Propose adding two optional fields to the root plugin.json manifest:

• privacyPolicyUrl
• termsOfServiceUrl

These are common publisher metadata fields already supported by existing plugin ecosystems, including Claude Code and OpenAI/Codex.

Standardizing them would allow plugin authors to declare these URLs once, rather than relying on client-specific extensions or marketplace-specific metadata.

Motivation

The current specification includes portable publisher metadata such as homepage, repository, and license, but does not provide dedicated fields for privacy policies or terms of service.

Both are commonly needed when distributing plugins through marketplaces or enterprise catalogs.

There is also existing precedent:

• Claude Code supports privacyPolicyUrl and termsOfServiceUrl in its plugin manifest.
• OpenAI/Codex supports privacyPolicyURL and termsOfServiceURL under its plugin manifest's interface object.

While these fields can be represented through client-specific extensions, the information itself is not client-specific. It describes the plugin publisher's policies regardless of which client consumes the plugin.

Proposal

Add two optional top-level string fields to plugin.json:

Example:

{
  "$schema": "https://agent-plugins.org/schemas/1.1.0/plugin.schema.json",
  "name": "example-plugin",
  "version": "1.0.0",
  "description": "Example plugin",
  "homepage": "https://example.com",
  "privacyPolicyUrl": "https://example.com/privacy",
  "termsOfServiceUrl": "https://example.com/terms"
}

Both fields would be optional and have no runtime semantics. Clients MAY display them in plugin discovery, installation, or management experiences.

The URLs describe the plugin publisher's policies and should not imply that they cover independently operated third-party services referenced by the plugin.

Proposed changes

• Add both optional fields to the manifest metadata definition in §5.
• Add corresponding string fields with URI format validation to plugin.schema.json.
• Document that clients MAY surface these URLs but are not required to retrieve or display them.
• Keep the fields optional, with no impact on plugin execution.

Open questions

1. Should HTTPS be required, or merely recommended?
2. Should invalid URLs be ignored rather than causing manifest validation to fail, given that these fields have no runtime impact?
3. Are there other existing implementations or naming conventions we should consider before standardizing these fields?