Skip to main content

Overview

ABP supports two discovery mechanisms depending on the type of ABP server: Web apps (HTTP URLs): Pre-flight HTTP-based discovery — fetch the HTML <head>, parse the manifest link, fetch the manifest JSON. This lets agents validate ABP support without launching a browser. Chrome extensions (local directory): Runtime-only discovery — launch the browser with --load-extension, discover the extension ID from browser targets, navigate to the ABP page, and discover capabilities via initialize() + listCapabilities(). No HTTP pre-flight is possible because chrome-extension:// URLs are not accessible from Node.js.

Web App Discovery

Before launching a browser, agents can check if a web app supports ABP by:
  1. Fetching the HTML <head>
  2. Parsing the manifest link
  3. Fetching the manifest JSON
This allows agents to validate ABP support and filter apps by capability without the overhead of browser automation.

Discovery Flow

Apps MUST include this in their HTML <head>:
Variations:

Manifest Format

The icon field should point to a 192x192 PNG image for best compatibility across agent UIs and app directories.

Example: Discovery Implementation

Usage

Chrome Extension Discovery

Chrome extensions cannot be discovered via HTTP. Instead, the client uses browser-side discovery:

Why No HTTP Discovery?

  • chrome-extension:// URLs are only accessible within the browser process — Node.js cannot HTTP-fetch them
  • Extensions don’t serve content over HTTP, so there is no HTML <head> to parse for a manifest link
  • The extension ID is dynamically assigned at load time (based on the extension’s directory), so the URL isn’t known in advance

What This Means for Extension Developers

  • No <link rel="abp-manifest"> needed — the ABP page doesn’t need a manifest link
  • No abp.json file required — though you can include one for documentation
  • listCapabilities() is essential — it’s the only way the client discovers full capability schemas
  • initialize() must return accurate capabilities — this is the primary discovery mechanism
See Chrome Extension Guide for complete implementation details.

Manifest vs Runtime

Use manifest for:
  • Deciding whether to load an app
  • Filtering apps by capability
  • UI display (app name, description, icon)
Use initialize() for:
  • Getting actual capability availability
  • Real-time requirements status
  • Starting a session

Caching

Manifests SHOULD be cached:
Clients can cache manifests to reduce network requests.

CORS

If the manifest is on a different origin, CORS headers are required:

Edge Cases

Version Compatibility

The manifest’s abp field declares the protocol version. Agents SHOULD handle version mismatches gracefully:
  • Same major version: Proceed normally.
  • Higher major version: Warn but attempt initialize() - runtime negotiation may succeed.
  • Lower major version: Proceed if agent supports backward compatibility.

Next Steps

Building ABP Apps

Create a manifest for your app

MCP Bridge Quick Start

Use discovery in practice

Protocol Overview

Complete protocol details