Discovery

Subscriby publishes a small set of well-known documents so that a client, a crawler or an AI agent that knows nothing about Subscriby can fetch one URL and learn which APIs exist, where each one's machine-readable description is, how to authenticate, where its documentation lives and where to check that it is up. Every document is built from the running application's configuration, the MCP server's own declarations and the tool catalogue, so none of them can name a host, a version or a count that the deployment does not have.

All of them answer GET, carry Cache-Control: public, max-age=3600 and need no credentials.

API catalogCopy Anchor Link

The catalog is the discovery document defined by RFC 9727. It lives on the main domain and on the API host, for clients that start there:

Both answer GET with the document and HEAD with a Link header that names the catalog under the api-catalog relation, as the RFC asks. The response is served as application/linkset+json with the RFC 9727 profile parameter and may be cached for an hour.

curl -s https://www.subscriby.net/.well-known/api-catalog | jq

The documentCopy Anchor Link

The catalog is a Linkset: one entry per API, each anchored on the URL that represents the API and carrying typed links.

{
  "linkset": [
    {
      "anchor": "https://api.subscriby.net/v1",
      "service-desc": [
        { "href": "https://api.subscriby.net/openapi.json", "type": "application/vnd.oai.openapi+json" }
      ],
      "service-doc": [
        { "href": "https://docs.subscriby.net/api/v1", "type": "text/html" },
        { "href": "https://docs.subscriby.net/webhooks/v1", "type": "text/html" }
      ],
      "service-meta": [
        { "href": "https://api.subscriby.net/.well-known/ai-plugin.json", "type": "application/json" }
      ],
      "status": [
        { "href": "https://api.subscriby.net/up" }
      ]
    },
    {
      "anchor": "https://mcp.subscriby.net",
      "service-doc": [
        { "href": "https://docs.subscriby.net/mcp/v1", "type": "text/html" }
      ],
      "service-meta": [
        { "href": "https://mcp.subscriby.net/.well-known/oauth-protected-resource", "type": "application/json" }
      ],
      "status": [
        { "href": "https://mcp.subscriby.net/up" }
      ]
    }
  ]
}

What each relation points toCopy Anchor Link

Link headers on the siteCopy Anchor Link

Every page of www.subscriby.net also advertises the machine-readable side of Subscriby in its Link response header (RFC 8288), so an agent that reads headers before HTML finds everything from the home page alone:

Link: <https://www.subscriby.net/.well-known/api-catalog>; rel="api-catalog"; type="application/linkset+json",
      <https://api.subscriby.net/openapi.json>; rel="service-desc"; type="application/vnd.oai.openapi+json",
      <https://docs.subscriby.net>; rel="service-doc"; type="text/html",
      <https://www.subscriby.net/llms.txt>; rel="describedby"; type="text/plain"

The same header carries the page's preload hints, which browsers act on; the four discovery relations are for machines and browsers ignore them.

Agent cardCopy Anchor Link

The agent card follows the A2A agent-card schema, version 1.0.0, and is honest about one thing an A2A client needs to know first: Subscriby's agent surface is its MCP server, so the card declares a single interface whose protocolBinding is MCP and says in its description that the A2A task methods are not served. An A2A client that reads the binding knows not to send a task there; a discovery crawler still learns the provider, the documentation, the two ways to authenticate and the skills.

{
  "name": "Subscriby",
  "description": "Subscriby runs paid memberships for communities on connected platforms: … Agents reach it over the Model Context Protocol (JSON-RPC 2.0 over Streamable HTTP) at the interface below, authenticating with OAuth 2.1 or a personal access token; the A2A task methods are not served.",
  "version": "5.0.6",
  "protocolVersion": "1.0.0",
  "provider": { "organization": "Envigo Innovations, LLC", "url": "https://www.subscriby.net" },
  "documentationUrl": "https://docs.subscriby.net/mcp/v1",
  "iconUrl": "https://static.subscriby.net/assets/brand/subscriby-emblem.png",
  "capabilities": { "streaming": false, "pushNotifications": false, "extendedAgentCard": false },
  "defaultInputModes": ["application/json"],
  "defaultOutputModes": ["application/json"],
  "supportedInterfaces": [
    { "url": "https://mcp.subscriby.net", "protocolBinding": "MCP" }
  ],
  "securitySchemes": {
    "oauth2": {
      "type": "oauth2",
      "flows": {
        "authorizationCode": {
          "authorizationUrl": "https://app.subscriby.net/oauth/authorize",
          "tokenUrl": "https://app.subscriby.net/oauth/token",
          "scopes": { "mcp:use": "Use the MCP server as the signed-in creator" }
        }
      }
    },
    "bearer": { "type": "http", "scheme": "bearer", "bearerFormat": "sbt_ personal access token" }
  },
  "security": [{ "oauth2": ["mcp:use"] }, { "bearer": [] }],
  "skills": [
    {
      "id": "projects",
      "name": "Projects",
      "description": "… MCP tools, gated by the abilities Archive Project, Create Project, …",
      "tags": ["archive_project", "create_project", "…"]
    }
  ]
}

• version is the deployed release, the same number the changelog names and the MCP server states in its handshake.
• The three capabilities are false because they describe A2A features (message/stream, push notifications, an authenticated extended card) that the interface does not serve; the MCP endpoint itself streams over Streamable HTTP.
• The OAuth endpoints are read from the same authorization-server metadata the MCP client follows, so the card and the metadata cannot name different URLs.
• Each skill is one group of the ability catalogue (projects, project operations, member support, teams, roles and groups, webhooks, API tokens, payments, pass windows, broadcasts, billing, account, analytics, activity log, distribution). Its description names the abilities the group's tools check and its tags are the MCP tool names, read from the server at request time, so a tool added to the server appears in the card with the same deploy.

MCP server cardCopy Anchor Link

The server card follows the shape proposed for MCP discovery in SEP-1649. It is deliberately small: identity, transport, protocol versions, authentication and capability flags with counts. The tool catalogue itself is linked (toolCatalogUrl), not copied, because the server describes its tools to a connected client over the protocol.

It is served on the main domain and on the MCP host:

{
  "serverInfo": {
    "name": "Subscriby",
    "title": "Subscriby MCP Server",
    "version": "5.0.6",
    "description": "Run paid memberships on connected community platforms: …",
    "websiteUrl": "https://www.subscriby.net"
  },
  "protocolVersion": "2026-07-28",
  "supportedProtocolVersions": ["2026-07-28"],
  "transport": { "type": "streamable-http", "endpoint": "https://mcp.subscriby.net" },
  "remotes": [{ "type": "streamable-http", "url": "https://mcp.subscriby.net" }],
  "authentication": {
    "schemes": ["oauth2", "bearer"],
    "resourceMetadataUrl": "https://mcp.subscriby.net/.well-known/oauth-protected-resource",
    "authorizationServers": ["https://app.subscriby.net"],
    "scopes": ["mcp:use"]
  },
  "capabilities": {
    "tools": { "listChanged": false, "count": 161 },
    "resources": { "listChanged": false, "count": 6 },
    "prompts": { "listChanged": false, "count": 0 }
  },
  "documentationUrl": "https://docs.subscriby.net/mcp/v1",
  "toolCatalogUrl": "https://api.subscriby.net/mcp-tools.json"
}

Every field is read from the server class, the package and the catalogue: the protocol versions are the ones the server negotiates, the listChanged flags are the ones it declares, and the counts are the live tool and resource registrations, so the card says exactly what the initialize handshake would. The counts above are illustrative; read the card for the current ones.

Agent skillsCopy Anchor Link

A skill is a short instruction file, SKILL.md, that an agent loads when it needs to work with Subscriby. The index follows the Agent Skills Discovery RFC 0.2.0 and lists three skills:

{
  "$schema": "https://schemas.agentskills.io/discovery/0.2.0/schema.json",
  "skills": [
    {
      "name": "subscriby-rest-api",
      "type": "skill-md",
      "description": "Call the Subscriby REST API: authenticate with a personal access token, page through lists, send an Idempotency-Key on every write, honour the rate limits and read the OpenAPI document.",
      "url": "https://www.subscriby.net/.well-known/agent-skills/subscriby-rest-api/SKILL.md",
      "digest": "sha256:…"
    }
  ]
}

Each file opens with YAML front matter carrying the same name and description as the index, followed by Markdown instructions. The digest is the SHA-256 of the exact bytes the file's URL serves, so a client can check that what it loaded is what the index promised. The instructions are generated from the application's configuration and the constants that enforce each rule: the hosts, the page-size ceiling, the idempotency window, the rate limits, the webhook retry schedule and the tool and event counts are the running values, never typed into the text.

curl -s https://www.subscriby.net/.well-known/agent-skills/subscriby-mcp/SKILL.md

OpenID Connect discovery aliasCopy Anchor Link

Some clients look for an authorization server's metadata only at the OpenID Connect discovery path. The authorization server (https://app.subscriby.net) therefore answers /.well-known/openid-configuration with the same RFC 8414 document it serves at /.well-known/oauth-authorization-server: the issuer, the authorization, token and dynamic-registration endpoints, the code response type, S256 as the only PKCE method, the mcp:use scope and the authorization_code and refresh_token grants. It is an OAuth 2.0 document at the OpenID Connect path, not an OpenID provider: there is no jwks_uri and no ID token. See Authentication for the flow.

Using it from an agentCopy Anchor Link

An agent that is handed subscriby.net and nothing else can resolve the whole surface in two requests: the catalog, then the OpenAPI document it points at. From there every operation, its abilities, its errors and the webhook events are described, and the quickstart explains how to obtain a token. An agent that speaks MCP instead reads the server card or follows the catalog's second entry to the MCP guide and connects with OAuth or a personal access token. An agent that works from skill files loads the three skills and has the rules of each surface in a page apiece.

See alsoCopy Anchor Link

• OpenAPI Specification, the document the catalog's service-desc link points at.
• MCP Server, the second API the catalog lists, and its Authentication page.
• Outbound Webhooks, the surface the third skill teaches.