Skip to main content

​
Overview

ABP uses dot-notation namespaces to organize capabilities: 
namespace.action
Examples:
  • export.pdf — Export as PDF
  • convert.markdownToHtml — Convert markdown to HTML
  • ai.summarize — Summarize text using AI
  • render.html — Render HTML with CSS

​
Standard Namespaces

​
export.* — Export Operations

CapabilityDescriptionInputOutput
export.pdfGenerate PDF from HTML content{ html, options }BinaryData (inline { document: BinaryData }, or the client generates a PDF from HTML returned by a convert.* capability)
export.imageExport as image (PNG, JPEG, SVG){ selector?, format }{ image: BinaryData }
export.htmlExport rendered HTML{ content, options }{ document: BinaryData }
export.markdownExport as Markdown{ content }{ markdown: string }

​
convert.* — Format Conversion

CapabilityDescriptionInputOutput
convert.markdownToHtmlConvert Markdown to HTML{ markdown, options }{ html }
convert.htmlToMarkdownConvert HTML to Markdown{ html }{ markdown }
convert.htmlToImageRender HTML as image{ html, options }{ image: BinaryData }
convert.csvToJsonConvert CSV to JSON{ csv, options }{ json }

​
render.* — Rendering Operations

CapabilityDescription
render.htmlRender HTML with CSS
render.canvasRender to canvas
render.svgRender SVG

​
ai.* — AI Operations

CapabilityDescriptionInputOutput
ai.summarizeSummarize text{ text, maxLength? }{ summary }
ai.translateTranslate text{ text, from, to }{ translated }
ai.completeText completion{ text, style }{ rewritten }

​
storage.* — Browser Storage

CapabilityDescription
storage.readRead from localStorage/sessionStorage
storage.writeWrite to localStorage/sessionStorage
storage.deleteDelete from storage

​
auth.* — Authentication

CapabilityDescription
auth.getTokenGet auth token from browser session
auth.getUserGet current user info

​
Forbidden Capabilities: Delivery and Input-Acquisition Mechanisms

Apps MUST NOT declare capabilities that wrap browser delivery mechanisms or input-acquisition APIs. These are browser features that route content to an OS-level destination (clipboard, share sheet, file dialog, notification) or acquire input through OS-level UI (file picker, camera prompt). An ABP capability should produce or consume data — the agent handles routing and acquisition on the host side.
For a decision test to identify these mechanisms, see the Implementation Guide — How to Recognize a Delivery Mechanism. The primary example is clipboard.*: apps MUST NOT declare clipboard.* capabilities. The browser Clipboard API requires user gestures that automated agents cannot provide, and clipboard is a host-side delivery mechanism — agents can write to the system clipboard directly using host tools (pbcopy, xclip, clip). Instead, expose the underlying content-producing capability (e.g., convert.markdownToHtml) and let the agent handle clipboard operations on the host side. The same principle applies to navigator.share(), showSaveFilePicker() / showOpenFilePicker(), new Notification(), and any future browser API that triggers OS-level UI. See the Protocol Overview for additional context on forbidden capabilities.

​
Vendor Namespaces

Vendors can use reverse-domain notation for custom capabilities: 
vendorDomain.namespace.action
Examples:
  • com.acme.imageFilter.blur
  • io.github.username.customTool

​
Naming Conventions

​
Action Verbs

Use consistent action verbs:
  • Create/Generate: export.pdf, generate.thumbnail
  • Read/Get: storage.read, auth.getToken
  • Write/Set: storage.write, storage.set
  • Convert/Transform: convert.markdownToHtml
  • Delete/Remove: storage.delete

​
Case Convention

  • Use camelCase for multi-word names
  • Namespace and action are separated by .
  • Examples: convert.markdownToHtml, auth.getToken

​
Capability Lifecycle

Capabilities progress through three stages: 
Experimental → Stable → Deprecated → Removed

​
Experimental

  • Marked with experimental: true in the manifest
  • May change without notice between versions
  • Agents SHOULD warn users when calling experimental capabilities

​
Stable

  • The default state (no experimental or deprecated flag)
  • Follow semantic versioning
  • Breaking changes only in major protocol versions

​
Deprecated

  • Marked with deprecated: true and optionally deprecationMessage
  • Deprecated capabilities MUST remain functional for at least one major version
  • The alternatives field SHOULD suggest replacement capabilities
  • Agents SHOULD warn users when calling deprecated capabilities
See the Protocol Overview for the full lifecycle details.

​
Next Steps

Examples & Tutorials

See capabilities in action

Building ABP Apps

Build your own app with capabilities

Protocol Overview

Full specification details