Agentic Resource Discovery: ai-catalog.json, Tool Trust, and Phone Agent Authorization

What Agentic Resource Discovery Solves

Agentic Resource Discovery, or ARD, is a way for agents to find tools, skills, and other agents without depending on a private list maintained by one platform. The direct answer: ARD standardizes how a provider publishes machine-readable capability metadata, how a registry or client discovers it, how publisher identity can be checked, and how the agent then connects through the capability's native protocol.

Google announced the Agentic Resource Discovery specification on June 17, 2026 as an open approach for publishing, discovering, and verifying agent resources across the web. The problem is practical. If every tool provider describes capabilities in a different place and format, an agent cannot reliably answer a simple question such as which service can book a meeting, retrieve an invoice, or expose a safe mobile action contract.

ARD changes the starting point from manual connector hunting to domain-published catalogs. A provider can publish an ai-catalog.json-style catalog under its own domain. A registry can crawl and index catalogs, and a client can either query that registry by intent or fetch a known partner catalog directly. That does not make the tool safe, enabled, or authorized. It gives the agent a structured way to know what exists before the product applies trust, policy, and execution controls.

How Catalogs and Registries Publish and Find Capabilities

The easiest way to understand AI agent resource discovery is to separate the publication path from the search path. A provider publishes a catalog that describes available resources: what a tool or agent is called, what it can do, where its interface lives, what protocol it uses, and what verification metadata is available. That catalog can also point to nested catalogs when an organization has several product areas.

A registry performs a different job. It crawls or ingests catalogs, indexes their descriptions, and returns matching resources when an agent asks for a capability by intent. For example, a client might search for a verified resource that can create calendar events or expose an MCP server for a specific enterprise product. The registry should return candidate resources and relevant verification metadata, not act as the execution broker.

The public ARD specification repository describes the specification, schemas, trust architecture, and reference work as an Apache-2.0 project. That matters because ARD is meant to describe many kinds of resources, not one vendor's connector store. Catalog entries may advertise MCP servers, A2A agents, OpenAPI tools, or nested catalogs, so the catalog is a discovery document rather than a replacement for the protocol that actually runs the capability.

What Publisher Verification Proves and Does Not Prove

Verification is useful because agents need to know whether a catalog really belongs to the publisher it claims to represent. Production discovery can include cryptographically verifiable publisher metadata before a direct native-protocol connection. That raises the quality of the trust decision: the agent is not merely reading an untrusted description found somewhere on the web.

Still, a verified publisher is not the same as an approved action. Verification can help answer questions such as: Is this catalog associated with the claimed domain? Has the metadata been tampered with? Is the resource description tied to a recognizable publisher? It does not prove that every advertised tool is harmless, that the endpoint will behave correctly tomorrow, or that the current user has authority to perform a consequential action.

For a trusted agent tool catalog, the next checks remain local and contextual. The runtime must validate endpoint compatibility, requested scopes, tool arguments, data exposure, user intent, and the action target. A verified finance publisher may still advertise a tool that requires careful approval before moving money. A verified messaging provider may expose a send action that should be shown to the user before completion. Correct identity reduces impersonation risk; it does not replace policy.

This distinction is especially important for phones, where the same device contains personal messages, work accounts, location, photos, authentication apps, health data, and payment surfaces. Discovery answers what resource exists. Authorization answers whether this user, on this device, in this context, should let the agent use it.

How ARD Hands Off to MCP, A2A, OpenAPI, and App Contracts

ARD is not a universal execution protocol. It is better understood as the signpost before the road. The catalog can tell an agent that a capability exists and which native interface to use. After that, the runtime still connects through the advertised protocol, such as MCP, A2A, OpenAPI, or a product-specific contract.

That handoff matters because protocols carry different assumptions. MCP can expose tools and resources to model-driven clients. A2A can describe agent-to-agent interaction. OpenAPI can define HTTP operations. A mobile app contract may expose a more constrained action surface through platform mechanisms or app-defined invocation rules. ARD can point to these interfaces, but it does not merge them into one protocol or guarantee that every Android app has a callable action contract.

For mobile teams, the practical question is whether a discovered capability can be invoked in a way that the phone runtime can validate. An app may advertise a capability, but the phone agent still needs a supported invocation path, predictable inputs, visible results, and error handling. Readers who want the app-side contract problem in more depth can use App Intents and Machine-Callable Apps for AI Agents, which focuses on how apps expose actions after discovery has identified them.

In other words, ARD can help a model find the right door. The native protocol determines how the door opens. The phone runtime decides whether this user should walk through it for this task.

Why Discovery Is Not Authorization on a Phone

The biggest design error is treating ai-catalog.json discovery as permission. A catalog can describe a resource, and verification can improve trust in the publisher, but Android authority is earned later through local controls. A phone agent must check whether the tool is enabled, whether the app or OS permission is available, whether the action target matches the user's request, and whether the action requires approval.

Android's own model reinforces this separation. The Android runtime permission guidance recommends requesting permissions in context when a feature needs them, and handling denied permissions remains the app's responsibility. A runtime permission can allow access to a device capability, but it does not approve a business consequence. Location access can enable a route search; it does not approve sharing a location with a contact. Contacts access can help prepare a message; it does not approve sending that message.

That is why phone-agent security needs more than discovery metadata. Skill permissions, action scopes, and user-facing approvals remain essential. For deeper treatment of reusable skills and Android permission checks, AI Agent Skill Security Needs Phone Permission Checks is the right companion. For identity, authority, and activity-record design across the full stack, see AI Agent Identity, Permissions, and Audit Trails: The Safety Stack Phone Agents Need.

A Pre-Connect and Pre-Execution Checklist for Discovered Resources

A discovered resource should pass through two gates before a phone agent uses it: pre-connect and pre-execution. The first gate decides whether the runtime should connect to the resource at all. The second decides whether a specific phone action should run for the current task.

1. Confirm the publisher. Check the domain, verification metadata, and catalog source before trusting the candidate resource.
2. Check catalog freshness. Compare timestamps, schema version, and resource status so stale entries do not drive current tasks.
3. Validate the native interface. Confirm whether the resource uses MCP, A2A, OpenAPI, or another contract the runtime can actually enforce.
4. Review requested scopes. Reject capability requests that exceed the task, especially when they touch messages, files, location, contacts, or account surfaces.
5. Require explicit enablement. A discovered tool should become usable only after the local runtime or admin policy enables it.
6. Start with a low-risk test. Prefer read-only or preview actions before any external-effect, device-control, sensitive-read, or destructive step.
7. Validate the action target. Confirm the recipient, app, account, file, setting, or destination before the tool runs.
8. Apply risk-based approval. Low-risk actions can be fast; consequential steps need visible review and an approval point.
9. Show the result. The user should be able to inspect what changed, what failed, or what still needs attention.
10. Keep stop and revoke paths available. The runtime should support disabling the tool, removing access, and recovering from failure.

This checklist keeps discovery useful without turning it into silent authority. It also gives developers a measurable test plan: a good resource registry should help the agent find candidates, while the phone runtime should remain responsible for whether any candidate can affect the device.

How FoneClaw Separates Catalog Visibility From Phone Authority

At FoneClaw, we treat catalog visibility as one input to a governed Android runtime. A configured compatible model can understand the request and plan the next step. FoneClaw invokes supported governed Android tools, handles visible results, guides permissions on demand, and applies tool policy before phone actions run.

Our current product facts make that distinction practical. FoneClaw 0.1.0 added per-tool search, enable controls, approval overrides, permission recovery, safer tool contracts, and trusted plugin continuation. The FoneClaw release data records those changes as release evidence. The FoneClaw public tool catalog is a dated snapshot with 118 built-in tools in 11 categories; in durable product language, we describe the runtime as having 100+ built-in tools with risk and approval labels.

That catalog is not an ARD implementation claim. It is a concrete example of the control pattern phone agents need: tools are visible, categorized, risk-labeled, and governed by local runtime policy. Built-in tools and signed plugin packages are also different surfaces. A plugin proposal must remain visible to the user, and installation should not be described as silent discovery.

When a model chooses a plan inside FoneClaw, the plan still has to meet the tool contract. If the task requires opening an app, reading the visible screen, preparing communication, handling location, running a workflow, or using a plugin, the runtime checks supported action scope and permissions. For the broader Android intent-to-action model, AI Agent Phone Control: How Android Phone Agents Turn Intent Into Action explains how governed phone execution differs from model reasoning.

What Teams Should Test Before Adopting an Agent Resource Registry

Teams evaluating Agentic Resource Discovery should test the whole path, not only the search result. A registry that returns many matches is not enough if those matches are stale, unverifiable, vague, or difficult to connect through a native protocol. A phone-agent team should measure discovery quality and execution safety independently.

The best adoption plan is incremental. Start with known partner catalogs or low-risk discovered resources, verify identity and interface behavior, then test phone-side policy with non-consequential actions. Expand only when discovery, verification, authorization, result handling, and revocation are each observable. ARD can make agent ecosystems easier to navigate, but phone trust depends on keeping every layer accountable.