Agent Readiness

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, need no credentials and may be read from any origin (Access-Control-Allow-Origin: *), so a validator or an agent running in a browser can fetch them. Beyond the documents, every page of the marketing site answers a request that prefers text/markdown with its text as Markdown; see Markdown for agents.

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.

AI capability manifestCopy Anchor Link

https://www.subscriby.net/.well-known/ai-catalog.json is an Agent Resource Discovery (ARD) manifest: one JSON file that lists every machine-readable document on this page, so a registry or an agent that finds it knows where everything else is without crawling. The manifest names the host as did:web:www.subscriby.net with a display name and a description, and each entry by a urn:air: identifier with its display name, media type, address, description and a few representative queries, the questions an agent would be asking when that document is the answer, so a registry can route a question to the right entry. Every marketing page links it with <link rel="ai-catalog"> in its head, and the robots file names it on an Agentmap: line, the way it names the sitemap. Like the other documents, every address in it is the running application's own.

curl -s https://www.subscriby.net/.well-known/ai-catalog.json

Agent cardCopy Anchor Link

The agent card follows the A2A 1.0 agent-card schema and lives at /.well-known/agent-card.json, the path the specification names. The card 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 and says in its description that the A2A task methods are not served. The specification asks a binding that is not one of its own (JSONRPC, GRPC, HTTP+JSON) to be identified by a URI, so the interface's protocolBinding is the MCP transport specification at the revision the server negotiates, which is also its protocolVersion. 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",
  "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": "https://modelcontextprotocol.io/specification/2026-07-28/basic/transports",
      "protocolVersion": "2026-07-28"
    }
  ],
  "securitySchemes": {
    "oauth2": {
      "oauth2SecurityScheme": {
        "flows": {
          "authorizationCode": {
            "authorizationUrl": "https://app.subscriby.net/oauth/authorize",
            "tokenUrl": "https://app.subscriby.net/oauth/token",
            "refreshUrl": "https://app.subscriby.net/oauth/token",
            "scopes": { "mcp:use": "Use the MCP server as the signed-in creator" },
            "pkceRequired": true
          }
        },
        "oauth2MetadataUrl": "https://app.subscriby.net/.well-known/oauth-authorization-server"
      }
    },
    "bearer": {
      "httpAuthSecurityScheme": { "scheme": "Bearer", "bearerFormat": "sbt_ personal access token" }
    }
  },
  "securityRequirements": [
    { "schemes": { "oauth2": { "list": ["mcp:use"] } } },
    { "schemes": { "bearer": { "list": [] } } }
  ],
  "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 and the metadata address 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, and names the server at its top level (name in the registry's reverse-DNS form, title, description, version, websiteUrl) the way a registry server.json does, which is how SEP-2127 shapes a card. 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. Both metadata documents and the dynamic registration endpoint can be called from a client running in a browser. See Authentication for the flow.

auth.mdCopy Anchor Link

auth.md is an open profile for agent registration: a Markdown file at the service root that walks an agent through obtaining a credential, paired with an agent_auth block in the OAuth authorization server metadata that names the registration endpoints. Subscriby serves the file on the main domain, the API host and the MCP host:

A credential always belongs to a creator, and the walkthrough offers three ways to obtain one: the OAuth 2.1 flow, in which the creator approves a client on the consent screen; a personal access token the creator mints by hand; and the profile's own registration, in which an agent names the creator's email address and the creator confirms a code. Nothing is granted to an agent that has only an email address. The file covers, in the order an agent needs them, the two discovery documents and the fields to read, which way in fits which kind of agent, each way step by step, where each credential works (an OAuth token on the MCP server, a personal access token on the MCP server and the REST API), the rate limits and the idempotency rule, the error envelope, and how a credential is revoked. Every address, scope, limit and lifetime in it is read from the running application.

The protected resource metadata the walkthrough starts from (https://mcp.subscriby.net/.well-known/oauth-protected-resource) names the resource, the authorization server and the scope, and also resource_name and bearer_methods_supported (header), the two fields RFC 9728 recommends.

curl -s https://www.subscriby.net/auth.md

Registering as an agentCopy Anchor Link

The profile's service_auth registration, also accepted under its identity_assertion type with a verified_email assertion, is for an agent that knows a creator's email address but has no browser session beside it. The agent_auth block of https://app.subscriby.net/.well-known/oauth-authorization-server names the endpoints in both of the profile's vocabularies (identity_endpoint and register_uri, claim_endpoint and claim_uri), the identity types and the one assertion type, and the document's grant_types_supported lists the claim grant urn:workos:agent-auth:grant-type:claim. The profile's anonymous registration is refused as anonymous_not_enabled.

1. POST https://app.subscriby.net/agent/identity with {"type": "service_auth", "login_hint": "<creator email>", "client_name": "<agent name>", "scope": "<ability values, space-separated>"}. scope is optional: ability values from the ability catalog, each one a token can be minted with; left out, the token carries every read ability and no write, so an agent asks for a write explicitly. The answer carries registration_id, a claim_token shown once and valid for thirty minutes, post_claim_scopes (the abilities the token will carry), and a claim block in the shape of RFC 8628: a six-digit user_code, the verification_uri of the signed-in claim page, expires_in (ten minutes) and the polling interval (five seconds). The request is answered the same whether or not a creator uses that address, so it reveals nothing about who uses Subscriby.
2. Show the creator the code and the address. The creator signs in, sees the agent's name, the abilities it asked for, the account they are signed in as and the team the token will act in, and types the code. The page refuses an account other than the one the agent named without repeating that address, and five wrong codes end the registration.
3. Poll POST https://app.subscriby.net/oauth/token with grant_type=urn:workos:agent-auth:grant-type:claim&claim_token=<claim_token>, no faster than the interval. Until the creator confirms, the answer is 400 with {"error": "authorization_pending"}; polling faster than the interval is slow_down; a lapsed, unknown or already redeemed registration is expired_token. The one successful poll answers {"access_token": "sbt_…", "token_type": "Bearer", "scope": "…", "registration_id": "reg_…"}: a personal access token for the creator's team carrying exactly the abilities post_claim_scopes listed, which works on the MCP server and the REST API, has no expiry of its own and appears on the creator's tokens page, where it can be deleted.

If the code lapses first, POST https://app.subscriby.net/agent/identity/claim with the claim_token, and the same email if one is given, issues a fresh code and page address for the same registration. Registrations are limited per address, per client and in total each hour. Refusals use the token endpoint's {"error", "error_description"} shape with the codes unsupported_identity_type, unsupported_assertion_type, invalid_request, invalid_scope, too_many_registrations, invalid_claim_token, claim_expired, email_mismatch and claimed_or_in_flight.

curl -s -X POST https://app.subscriby.net/agent/identity \
  -H "Content-Type: application/json" \
  -d '{"type": "service_auth", "login_hint": "creator@example.com", "client_name": "My agent"}'

Web Bot Auth key directoryCopy Anchor Link

Subscriby signs the requests it sends to other servers, which today are its webhook deliveries, with Web Bot Auth: an RFC 9421 HTTP message signature made with an Ed25519 key, carried in Signature-Agent, Signature-Input and Signature headers. The public key is published at https://www.subscriby.net/.well-known/http-message-signatures-directory as a JWK set with the media type application/http-message-signatures-directory+json; the response is itself signed for the host it was requested at, with the tag http-message-signatures-directory, and each key's kid is its RFC 8037 thumbprint. A receiver, or Cloudflare in front of one, verifies a delivery against that key without knowing the endpoint's secret. The signature verification page shows the headers on a delivery.

curl -si https://www.subscriby.net/.well-known/http-message-signatures-directory

WebMCPCopy Anchor Link

Every marketing page registers tools with a browser that implements WebMCP, the model-context API that lets a page offer an agent driving the browser a set of callable tools instead of a surface to scrape. The five tools are read_current_page, read_page and open_page (every key page of the site, by name), compare_with (any comparison page, by the other tool's name) and estimate_fees (the fee calculator for a number of members at a price). Each read is answered as Markdown through the site's own Markdown negotiation. The pages, the comparisons and the calculator's bounds are emitted by the server into the page, so the tools follow the site with each deploy; a browser without the API registers nothing and loads nothing extra.

Markdown for agentsCopy Anchor Link

Every page of www.subscriby.net is also served as Markdown. Send a request whose Accept header prefers text/markdown over text/html and the answer is the page's text instead of its layout:

curl -s -H "Accept: text/markdown" https://www.subscriby.net/pricing

• The response is Content-Type: text/markdown; charset=UTF-8, carries Vary: Accept, an x-markdown-tokens header with an estimate of the tokens in the body, the site's Content-Signal directives and a Link header that names the HTML page as its alternate; the HTML page names the Markdown the same way.
• Pages written from the site's catalogues (the home page, pricing, features, payment methods, integrations, the calculator, comparisons, use cases, the switching guides, connectors, the changelog, the blog, about and the press kit) answer the same text llms-full.txt inlines for them, in English and with the English addresses, like that file. The home page answers the llms.txt index itself. Pages written as prose (the legal pages) are converted from their HTML in the language of the address.
• A browser never asks for Markdown and a bare */* is answered with HTML, so nothing changes for people. Accept: text/markdown;q=0.5, text/html is HTML too: the Markdown is served only when it is preferred. The Markdown answer is produced fresh on every request.

Markdown twinsCopy Anchor Link

Every page the catalogues describe is also served as Markdown at its own address with .md appended, for an agent that follows addresses rather than negotiating: https://www.subscriby.net/pricing.md, https://www.subscriby.net/features/pass-series.md, and for the home page https://www.subscriby.net/index.md or README.md. The twin opens with YAML front matter (title, description, canonical_url), carries the same text the negotiation answers with, names the HTML page as its canonical and its alternate in the Link header, and ends with a Sitemap section that links the Markdown sitemap below. The legal pages, written as prose, have no twin and answer through negotiation alone.

curl -s https://www.subscriby.net/pricing.md

AGENTS.mdCopy Anchor Link

https://www.subscriby.net/AGENTS.md (also /agents.md and /.well-known/AGENTS.md) is the briefing an agent reads first: what Subscriby is as a service, the three ways to a credential, the REST API, the MCP server and the webhooks in a paragraph each, the conventions every surface shares, the operations that need a human before they run, what never to do, and where every longer document is. Like the skills and auth.md, every address, count and limit in it is read from the running application.

curl -s https://www.subscriby.net/AGENTS.md

Sitemap for agentsCopy Anchor Link

https://www.subscriby.net/sitemap.md (also /.well-known/sitemap.md) lists every page of the marketing site by section with a one-line summary each, the same lines as llms.txt, under a heading that says what the file is and where the Markdown twins are.

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; the AI capability manifest lists every document on this page in one file, with the questions each one answers. From there every operation, its abilities, its errors and the webhook events are described, the quickstart explains how to obtain a token, and auth.md says the same in the agent's own terms. 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.