Capability Tags
Capability tags are descriptive signals for what a resource can do. They help users, Discovery nodes, SDKs, and semantic retrieval systems understand a resource’s task surface. They are useful for matching and ranking, but they do not grant authority.
This page is paired with Authorized Domains because the difference is easy to miss. authorizedDomains answers “where is this resource or node allowed to operate?” capabilityTags answers “what can this resource do?” Both may appear in a registration form and both may influence Discovery UX, but only authorized domains are governance scope.
Good Capability Tags
Good tags are short, specific, and capability-oriented. They describe actions, protocols, tasks, interfaces, or functional strengths. Examples include:
summarizationcontract-reviewmcp-servertool-callingcode-analysisretrievalworkflow-automationsemantic-searchagent-serviceapi-integration
Bad tags are too broad, too promotional, or too domain-confusing. best, powerful, enterprise, and AI are weak because they do not help matching. A domain name used as a tag can be acceptable when it describes a capability context, but it must not be mistaken for authorization. A resource tagged finance is not authorized for finance unless authorizedDomains and the publication path support that scope.
How Tags Help Discovery
Discovery can use tags in several ways. A simple query engine can match tags directly. A semantic engine can combine tags with resource descriptions, examples, protocol fields, and DID Document metadata. A UI can let users filter candidates by tags. An SDK can expose tags in result cards so agents can choose between similar resources.
In OAN’s semantic Discovery direction, tags are part of a richer resource surface rather than the whole ranking model. The GRAIL research direction, for example, focuses on deeper semantic retrieval for agent resources, where query intent, metadata, examples, and structured fields can all matter. Tags remain valuable because they are compact and explicit.
Tags As Retrieval Features
In a serious Discovery system, tags are features in a retrieval model. They can support lexical matching, candidate recall, semantic reranking, result explanation, and UI filtering. They are especially useful when resource descriptions are long or inconsistent. A concise tag such as code-analysis can help connect several descriptions that use different wording.
But tags should remain features, not authority. A retrieval model can weigh tags heavily for relevance while still applying lifecycle, proof, and domain checks before returning trusted candidates.
Tags Are Not Proof
A tag is a claim made in metadata. It should be indexed and displayed, but it should not be treated like proof. If a skill says contract-review, that helps a user find it; it does not prove legal accuracy. If an MCP server says data-access, that helps a client understand the tool surface; it does not prove the server is authorized to access a private dataset. If a tool says healthcare, that does not override authorized-domain scope, enterprise policy, or safety checks.
The correct trust sequence is: use tags to help find candidates, then verify evidence before use. Discovery is allowed to rank by relevance, but it should return evidence-carrying candidates. Clients should verify Root proof, package hashes, lifecycle status, domain scope, and endpoint binding as appropriate.
Tags in User Interfaces
The website uses chip-style inputs for capability tags. This is a small UX choice with a real benefit: users do not need to guess whether commas, semicolons, or line breaks separate tags. Pressing Enter turns a phrase into a visible tag component. The same pattern is appropriate in SDK examples and skill-assisted workflows: make tags explicit objects, not fragile strings.
For registration, the tag input helps publishers describe resources more accurately. For discovery, tag input lets users constrain or hint their intent. In both cases, the UI should keep capability tags visually distinct from authorized domains so users learn the difference through the form itself.
Relationship to Resource Type
Capability tags complement resource type. Resource type says what kind of resource this is: Agent Service, Skill, MCP Server, or Tool/API. Tags say what the resource does or exposes. Two MCP servers may have completely different tags. A skill and a hosted service may both have summarization but differ in how a consumer installs or invokes them.
This separation lets Discovery support both coarse and fine-grained filtering:
| Field | Example | Meaning |
|---|---|---|
| Resource type | mcp_server |
The consumer should expect an MCP connection model. |
| Capability tag | contract-review |
The resource claims a contract-review capability. |
| Protocol | mcp or https |
The interaction or access protocol. |
| Authorized domain | legal |
The governance domain scope, not a ranking tag. |
Tag Quality Affects Ecosystem Quality
Poor tags make Discovery noisy. Overloaded tags return too many irrelevant candidates. Missing tags hide useful resources. Misleading tags may pass basic string checks but disappoint users and weaken trust in the network. As OAN grows, community examples, SDK helpers, and Registrar-side suggestions should guide publishers toward precise tags.
Registrar-side tooling can recommend tags after inspecting descriptions, manifests, schemas, or examples, but the final registration material should still be clear and reviewable. For public resources, tags become part of how humans and agents understand the ecosystem.
Tag Governance Should Stay Lightweight
Unlike authorized domains, capability tags should not require heavy governance for every new phrase. The ecosystem needs room for emerging tasks, new protocols, and domain-specific vocabulary. A lightweight approach works better: encourage standard tags, allow custom tags, provide suggestions, and let Discovery learn from usage.
The boundary is that lightweight tags must not become hidden permissions. If a tag starts affecting authority rather than retrieval, it has crossed into domain or policy territory and should be redesigned.