How does an AI agent discover how to authenticate to the OntoRamp MCP server?

An unauthenticated request returns HTTP 401 with a WWW-Authenticate Bearer challenge whose resource_metadata parameter (RFC 9728 §5.1) points at https://mcp.ontoramp.com/.well-known/oauth-protected-resource. That document is an RFC 9728 OAuth 2.0 Protected Resource Metadata file: it names the resource (https://mcp.ontoramp.com), the supported Bearer method (["header"]), the access scopes (["read","read+write"]), and a documentation link. The agent reads it to learn it must send an API key as an Authorization: Bearer header.

Does OntoRamp implement RFC 9728?

Yes — the protected-resource-metadata discovery layer. OntoRamp serves the RFC 9728 §3.1 well-known document at https://mcp.ontoramp.com/.well-known/oauth-protected-resource and signals it from the 401 via the RFC 9728 §5.1 resource_metadata parameter. RFC 9728 requires only the resource field; the document also includes the RECOMMENDED and OPTIONAL fields bearer_methods_supported, scopes_supported, resource_name, and resource_documentation.

Does OntoRamp run an OAuth authorization server?

No. OntoRamp authenticates with a static API key carried as a Bearer token (RFC 6750 header method). The protected-resource-metadata document deliberately omits the authorization_servers field because there is no OAuth authorization server, no token endpoint, and no authorization-code or PKCE flow. The document is a valid RFC 9728 file, but because it has no authorization_servers it is not a Model Context Protocol authorization-profile-conformant resource (the MCP profile requires that field). To authenticate, register a key and send it as a Bearer token.

What is in OntoRamp’s protected-resource-metadata document?

resource: https://mcp.ontoramp.com; bearer_methods_supported: ["header"]; scopes_supported: ["read","read+write"] (the API-key access levels — read for the free tier, read+write for Developer tier and above); resource_name: "OntoRamp MCP"; resource_documentation: https://ontoramp.com/docs/agent-authentication. There is no authorization_servers field.

RFC 9728 Protected Resource Discovery for AI Agents

RFC 9728 protected-resource discovery for AI agents

RFC 9728 — OAuth 2.0 Protected Resource Metadata — lets a protected resource publish a machine-readable document describing how to authenticate to it, and lets the resource point an unauthenticated caller at that document straight from the 401 response. An AI agent can then learn the auth requirement programmatically — no human reading docs.

OntoRamp's MCP server implements the RFC 9728 discovery layer. It authenticates with a static API key sent as a Bearer token — it does not run an OAuth authorization server — so the worked example below shows exactly that: discover the metadata, read that the auth is a Bearer header, register a key, and call.

Step 1 — the 401 points at the metadata

Call the MCP endpoint without credentials and the server answers 401 with a WWW-Authenticate Bearer challenge. Per RFC 9728 §5.1, the resource_metadata parameter carries the URL of the metadata document:

WWW-Authenticate: Bearer realm="OntoRamp MCP", error="invalid_token",
  error_description="Provide a valid OntoRamp API key as a Bearer token;
  register at https://ontoramp.com/mcp", error_uri="https://ontoramp.com/mcp",
  resource_metadata="https://mcp.ontoramp.com/.well-known/oauth-protected-resource"

Step 2 — the protected-resource-metadata document

Fetch that URL (unauthenticated). Per RFC 9728 §3, it returns a 200 application/json document. resource is the only required field; OntoRamp also publishes the supported Bearer method, the access scopes, a name, and a documentation link:

GET https://mcp.ontoramp.com/.well-known/oauth-protected-resource
200 OK · application/json

{
  "resource": "https://mcp.ontoramp.com",
  "bearer_methods_supported": ["header"],
  "scopes_supported": ["read", "read+write"],
  "resource_name": "OntoRamp MCP",
  "resource_documentation": "https://ontoramp.com/docs/agent-authentication"
}

bearer_methods_supported: ["header"] — present the credential in the HTTP Authorization header as a Bearer token (RFC 6750 §2.1). OntoRamp does not accept body or query tokens.
scopes_supported: ["read", "read+write"] — the access levels a key can hold: read on the free tier, read+write on Developer tier and above.
No authorization_servers — there is no OAuth authorization server to discover (see below).

Step 3 — register a key and call with a Bearer token

The metadata tells the agent everything it needs: authenticate with a Bearer header. Register a free key on the MCP plugin hub, then send it on every Model Context Protocol request:

POST https://mcp.ontoramp.com/mcp
Authorization: Bearer YOUR_API_KEY
Content-Type: application/json

What this is — and what it isn't

OntoRamp implements RFC 9728 protected-resource-metadata discovery: a standards-based, machine-readable way for an agent to learn how to authenticate. That is the whole of what the document above delivers.

It is not an OAuth authorization-code flow. There is no authorization server, no token endpoint, no dynamic client registration, and no PKCE exchange — which is why the metadata omits authorization_servers. The document is a valid RFC 9728 file, but because it carries no authorization server it is not a Model Context Protocol authorization-profile-conformant resource (that profile requires the field). Authentication is exactly one step: register a key, send it as a Bearer token.

See also agent authentication for the Bearer-key basics, agent discovery for the machine-readable capability descriptors, and the MCP API reference for every tool, parameter, and response shape.