Resource Types

OAN starts with four first-class resource types: Agent Service, Skill, MCP Server, and Tool/API. They share the same identity, registration, Root acceptance, package, Discovery, and verification model, but each one preserves its own native runtime or artifact semantics.

This resource-type model is what keeps OAN from becoming a narrow agent directory. The agent ecosystem already contains services, packages, servers, and APIs. OAN gives them a common trust envelope without forcing them into one interaction protocol.

Resource-first design is one of OAN’s main strategic choices. Many adjacent systems begin from one object, such as an agent card, an MCP server listing, a tool endpoint, or a package marketplace. OAN starts from the broader idea of an agent-facing resource, then lets the resource declare its native form.

OAN resource types

The Four Types

Resource type Typical subject Native next step
Agent Service Hosted service with agent-facing behavior. Verify evidence, then invoke service protocol.
Skill Reusable capability package or manifest. Verify package evidence, then install or load.
MCP Server MCP-compatible endpoint exposing tools, prompts, or resources. Verify evidence, then connect through MCP.
Tool/API Endpoint or schema-described callable capability. Verify evidence, then call API with normal auth and policy.

The type should be chosen by the resource’s actual integration surface, not by marketing language. A hosted endpoint is not a Skill merely because it is useful to agents. A package is not an Agent Service unless it exposes a service-like runtime.

This discipline improves interoperability. If resource types become vague, clients cannot know what verification should bind or what native protocol comes next. Correct typing lets the SDK, website, community skill, and Discovery UI ask better questions.

Shared OAN Envelope

Every resource type should be able to carry:

  • did:oan identity;
  • DID Document and verification methods;
  • resource type metadata;
  • description and examples;
  • authorizedDomains;
  • capabilityTags;
  • endpoint, manifest, schema, repository, or artifact references;
  • version and package facts;
  • hashes and Root proof;
  • lifecycle state.

This shared envelope makes Discovery and verification consistent. It also lets SDKs and skills offer common workflows while still collecting resource-specific fields.

The shared envelope is also what lets future Discovery improvements benefit every type. Semantic search can use descriptions and examples. Domain filtering can apply consistently. Lifecycle state can be interpreted consistently. Verification can follow the same high-level chain even when the final invocation differs.

Type-Specific Modeling

Agent Services should emphasize service endpoint, protocol, invocation expectations, authentication hints, and supported operations. Skills should emphasize manifest location, package version, installation surface, examples, and artifact hash. MCP Servers should emphasize MCP transport endpoint, exposed tools/resources/prompts, and connection requirements. Tool/API resources should emphasize endpoint, schema, authentication, rate limits, and input/output shape.

The distinction matters for consumers. A user discovering a Skill expects installation or package retrieval. A user discovering an MCP Server expects an MCP connection. A user discovering a Tool/API expects API invocation. OAN should not hide those differences under a generic “agent” label.

The distinction also matters for proof. A Skill may need artifact hash binding. An MCP Server needs endpoint and protocol binding. A Tool/API benefits from schema hash binding. An Agent Service needs service endpoint and invocation-profile clarity. The ResourcePackage should capture the facts that make that type verifiable.

Future Resource Types

The current four types are enough to cover many practical integrations, but the model can grow. Future resource types might include prompt packages, workflow packages, dataset resources, model endpoints, evaluation suites, domain policy packs, or other agent-facing assets. A new type should be added only when it has distinct metadata, verification, or invocation expectations.

The rule for future types is the same: keep the native format, add OAN identity and publication evidence, and make Discovery return verifiable candidates.

New types should not be added merely because a marketing category appears. They should be added when clients need different validation rules, different metadata, different proof binding, or different post-verification behavior. Otherwise, capability tags and descriptions may be enough.

What Developers Should Implement

Developers building resource integrations should provide typed constructors or validators for each resource type. They should also expose examples that show correct authorizedDomains, useful capabilityTags, and package references. The goal is to make the right thing easier than a vague free-form registration.

For UI developers, resource type selection should change the fields shown to the user. For SDK developers, resource type should affect validation and helper methods. For skill authors, resource type should shape the assistant’s questions.

For protocol adapter developers, resource type should shape the handoff after verification. An MCP adapter should not treat a Tool/API endpoint as an MCP server. An A2A-style adapter should not assume every Agent Service has the same task protocol. OAN gives adapters trust context; adapters preserve native protocol meaning.

Further Reading