MCP Server Integration

MCP servers can be published as OAN resources without replacing MCP. OAN helps users and agents discover a server through a governed trust path; MCP remains the protocol for connection, tool listing, resource access, prompt handling, and runtime interaction.

This is a clean division. OAN answers “which MCP server is this, who published it, what did Root accept, and can I verify the result?” MCP answers “how do I connect, initialize, call tools, and exchange context?”

That division lets OAN complement the MCP ecosystem instead of competing with it. MCP is excellent at exposing tools and context to clients. OAN adds the pre-connection trust path: discover the server, verify its identity and package facts, then let MCP do MCP work.

OAN resource types

What To Register

An MCP Server resource should include:

  • resourceType set to the MCP server type used by the implementation;
  • a did:oan subject and DID Document;
  • MCP endpoint or transport information;
  • summary of exposed tools, resources, and prompts when available;
  • protocol binding that tells consumers this is MCP-facing;
  • authorizedDomains;
  • capabilityTags describing the task surface;
  • version and package metadata;
  • hashes and Root-verifiable package facts.

The goal is not to mirror the entire live MCP tool list if that list changes frequently. The goal is to publish enough stable public metadata for Discovery and verification. Dynamic runtime details can still be negotiated through MCP after connection.

If the server’s public tool families change significantly, publish a new version. If only transient runtime state changes, do not force it into OAN metadata. A useful rule is: put stable discovery and verification facts in OAN; leave live session details to MCP.

Discovery Before MCP Initialization

An MCP client or agent runtime can query Discovery for a needed capability, receive MCP Server candidates, verify OAN evidence, and only then initialize the MCP connection. This prevents the client from connecting to a random endpoint merely because it matched a text query.

The flow should look like this:

  1. Query Discovery for an MCP-compatible resource.
  2. Inspect candidate description, tags, domains, endpoint, and lifecycle.
  3. Verify Discovery response, Root proof, package hashes, and DID identity.
  4. Confirm the MCP endpoint matches verified package material.
  5. Start MCP initialization and tool negotiation.
  6. Apply ordinary MCP and application-level safety controls.

OAN does not remove the need for MCP’s own protocol checks.

The endpoint binding step is worth special attention. A client should not verify an OAN package and then connect to a different MCP endpoint supplied out of band. The endpoint used for MCP initialization should match the verified package or a verified redirect policy.

Modeling Tools and Resources

MCP servers can expose many tools, prompts, and resources. OAN metadata should summarize them in a way that helps Discovery. For example, a server might declare tags such as knowledge-retrieval, document-search, or repository-analysis, and include a description of its tool families.

For large or dynamic servers, avoid stuffing every transient tool detail into static OAN metadata. Instead, register stable capabilities and point to a manifest or schema reference if appropriate. The client can retrieve live MCP details after verification.

For Discovery quality, examples can be more useful than exhaustive lists. A server that explains “searches internal engineering documents and returns citation-backed snippets” is easier to retrieve semantically than a server with ten generic tool names and no task description.

Security Boundary

OAN verification should happen before connection, but MCP runtime safety still matters after connection. A verified MCP server can still expose risky tools. A tool call may still require user confirmation, sandboxing, authentication, data-access policy, or enterprise review.

The correct claim is: “this MCP server candidate came through an OAN-verifiable path.” The incorrect claim is: “this MCP server is automatically safe to call.”

In enterprise environments, MCP connection policy may depend on data classification, user role, workspace, and tool permissions. OAN can be one input into that policy. It should not be the only control.

Version and Endpoint Changes

If an MCP server changes endpoint, transport, public capability surface, or package reference, publish a new version. The DID can remain stable while the ResourcePackage captures updated facts. Discovery can then expose the current version and clients can verify the version they intend to use.

This is especially important for long-running agent environments. A server discovered last month may not be the same server a client should use today unless lifecycle and package facts still match.

For MCP registry projects, OAN can act as a trust wrapper. Existing registry metadata can be mapped into an OAN ResourcePackage, and clients can verify OAN evidence before using registry-provided connection details.

Further Reading