For Product Builders

Product builders use OAN to make agent-facing resources easier to discover and safer to evaluate. If you publish a Skill, MCP Server, API, or Agent Service, OAN gives you a way to attach identity, metadata, domain scope, package evidence, and lifecycle to that resource.

You do not need to run the whole network to begin. Start by registering one resource through official services or the community skill, then verify that Discovery can find it and that the result carries useful evidence.

This is a low-risk way to make a product more discoverable. You can keep your existing service, package, API, or MCP implementation. OAN adds identity, publication evidence, and Discovery visibility around it. The product does not have to become “OAN-native” internally.

OAN resource types

What Builders Get

OAN gives builders:

  • a stable did:oan identity for the resource;
  • a structured way to describe resource type and capabilities;
  • a governed registration path;
  • Root-verifiable package evidence;
  • Discovery visibility;
  • lifecycle state for updates and revocation;
  • SDK and skill surfaces for automation.

This helps a resource become more than a link in a README. It becomes a discoverable object with a trust path.

That trust path can also become a product differentiator. Users and agents can see not only that your resource exists, but which version was accepted, which domains it claims, how it should be invoked, and what evidence can be verified before use.

What Builders Need To Provide

Builders should provide accurate metadata. That includes resource type, description, endpoint or artifact reference, authorized domains, capability tags, version, hashes, and DID material. The better the metadata, the better Discovery works. The better the hashes and package references, the stronger verification becomes.

Do not treat registration as advertising copy. OAN metadata should help users and agents decide whether the resource is relevant and how to verify it.

Good metadata is specific without being noisy. It should describe the task surface, integration surface, constraints, examples, and version. Avoid broad claims such as “does everything” or “universal AI tool”; they hurt semantic retrieval and user trust.

Product Examples

A developer tooling company can register a code-analysis API. A research assistant team can register a document summarization skill. A SaaS provider can register an Agent Service that performs workflow automation. A data platform can register an MCP Server for controlled knowledge retrieval.

In each case, OAN does not replace the product. It makes the product discoverable and verifiable before use.

This is why OAN can work for both startups and internal platform teams. A small builder can publish one public skill. A larger product team can register a family of APIs or services. Both use the same identity and proof vocabulary.

Updates and Lifecycle

Builders should plan for updates. If a skill changes version, an API schema changes, an endpoint moves, or a capability surface changes, publish updated package material. Keep the DID identity stable when continuity is intended, and let lifecycle state show what version is current.

This is especially important for fast-moving skill and MCP ecosystems. Users need to know whether they are installing the latest active version or an old package.

Plan your release workflow so OAN publication is part of version release, not an afterthought. When you update a skill manifest, API schema, or MCP endpoint, prepare the new package facts at the same time. That habit prevents Discovery from pointing to stale integration material.

How To Start

Start small:

  1. Pick one real resource.
  2. Write a precise description.
  3. Choose the correct resource type.
  4. Select honest authorized domains.
  5. Add useful capability tags.
  6. Register through the official path.
  7. Query Discovery and inspect the evidence.
  8. Use SDK or skill automation only after the manual flow makes sense.

After the first resource works, improve the loop. Add better examples, refine tags, test semantic queries, verify SDK behavior, and document the native protocol step. The goal is not only to be registered; it is to be easy to find, verify, and use correctly.

Further Reading