{
  "schemaVersion": "1.0",
  "type": "research-article",
  "runtimeAvailable": false,
  "id": "proof21:journal:discovery-is-not-authorization:en",
  "inLanguage": "en",
  "slug": "discovery-is-not-authorization",
  "title": "Discovery is not authorization.",
  "description": "Help agents understand a service without implying that a directory listing, a schema, or a paid request makes it safe to use.",
  "datePublished": "2026-09-07",
  "dateModified": "2026-09-07",
  "url": "https://proof21.xyz/journal/discovery-is-not-authorization/",
  "markdownUrl": "https://proof21.xyz/journal/discovery-is-not-authorization/article.md",
  "markdown": "# Discovery is not authorization.\n\n**Design note · 7 September 2026 · Proof21 publishes static learning resources, not a live agent service.**\n\nAn agent cannot use a capability it cannot identify. It needs to know what a service does, what it expects, what it returns, and which permissions it requires. But discoverability is only the beginning of the decision. Finding a tool is not permission to call it, and calling it successfully is not proof that its claims are true.\n\nFor Proof21, this distinction shapes both the website and the proposed runtime. Human readers should find concrete jobs and honest limitations. Machines should find equivalent structured resources, not a more optimistic version of the product hidden in an API description. The public learning surface must not invent an endpoint simply because a standard has a field for one.\n\n## Use the right discovery surface for the job\n\nThe MCP Registry describes a discovery and distribution role for MCP server metadata. A2A discovery uses agent information to help clients locate and understand compatible agents. x402 Bazaar provides a discovery surface for paid resources. Their documentation describes different interfaces and ecosystems; a listing in one does not automatically make a service conformant to the others. [1][2][3]\n\nA proposed integration should start with the actual service contract and supported protocol revision. Publish the input and output schema, operational status, authentication requirements, permissions, and relevant limitations. Identify which metadata is descriptive and which fields a client can validate. A client still needs a local policy about acceptable providers and actions.\n\nDo not publish a placeholder that looks executable. A documentation URL, a downloadable example, and a production endpoint should have different resource types and status labels. Proof21's current agent entry is a reading and offline-learning surface. It is not a running MCP server, an A2A agent, or an available paid checking API.\n\n## Make the first question concrete\n\nImagine an agent asked to review a completed payout. A useful discovery description would explain that a proposed financial-checking profile compares a named instruction with supported execution evidence. It would name the bindings and possible outcomes, including unresolved evidence. It would not merely claim to “add trust to AI.”\n\nThe agent should learn what the tool does not do as well: it does not hold keys, send the payout, guarantee every chain's finality, or convert a service receipt into proof of downstream work. This lets a controller choose a read-only evidence workflow instead of accidentally granting payment permissions. The action boundary should be visible before any credential is requested.\n\nExamples should be small enough to inspect and honest about their source. A synthetic request and result can teach the schema without being presented as a real customer transaction. Link the explanation, the raw artifact, and the test that exercises it. A screenshot alone is a weak machine interface and a poor basis for reproducing behavior.\n\n## Publish the same meaning in every format\n\nA human article, an agent-readable Markdown edition, and a structured resource should describe the same status and limits. If the article says a capability is proposed while its machine metadata says it is live, the system has created a safety-relevant contradiction. Version identifiers and content digests help detect drift, but they do not replace review of the meaning.\n\nA practical static resource can carry a stable identifier, language, canonical page, source revision, complete body, citations, related resources, and a clear content type. A resource index should distinguish documentation from runtime tools. Full text should remain readable without animation or a JavaScript-only interface; an agent should not need to interpret a decorative video to discover a critical restriction.\n\nLocalization belongs in that same contract. Translate explanations and questions fully, while preserving protocol identifiers, code, signing inputs, and status enumerations. Equivalent-page language links help people compare the same subject rather than return them to a generic homepage. Arabic directionality should not reorder technical identifiers in a way that changes what a reader copies.\n\n## A listing cannot grant a credential\n\nDiscovery content is untrusted input. A tool description that asks an agent to ignore its instructions, reveal a token, or call an unrelated endpoint is not authorization. The controller must bind credentials to the intended service and requested scope. MCP's authorization specification treats resource and token boundaries explicitly; a compatible implementation must follow the revision it claims, not simply copy a logo. [4]\n\nThe same principle applies to URLs embedded in evidence. Fetching should be constrained by protocol, destination, size, redirects, and timeouts. A directory should not become a route to internal metadata services or a mechanism for carrying ambient credentials to arbitrary hosts. Reading about a service should not automatically trigger execution, payment, or outreach.\n\nProvider reputation may help a consumer decide where to investigate, but it is not a replacement for evidence about this particular operation. A listed service can return a stale observation or an authentic negative result. A controller should evaluate those outcomes under policy rather than assume every listed provider is safe for every job.\n\n## Test understanding before measuring adoption\n\nA narrow pilot can ask an independent client to find the correct resource, identify its permissions, distinguish the offline example from a live API, and explain an unresolved result. Test both structured and Markdown paths. Remove animation and disable JavaScript to confirm that the substantive content remains available.\n\nMeasure successful resource retrieval separately from actual authorized tool use and from independent acceptance of an output. Page views, directory presence, and generated examples are not paying customers. Proof21 should earn runtime integrations by implementing and testing a concrete contract, not by making its static discovery metadata sound production-ready before the service exists.\n\n## Frequently asked questions\n\n### Is agent discovery just search optimization?\n\nThere is overlap in making content findable, but an executable integration also needs a precise contract, compatible transport, authentication, permission boundaries, and a consumer policy. Visibility alone does not supply those properties.\n\n### Does a registry listing guarantee that agents will use a service?\n\nNo. It can help clients discover metadata. Selection, authorization, successful execution, and repeat demand are separate outcomes that must be measured rather than inferred from the listing.\n\n### Can an agent call Proof21's website as a live checking API today?\n\nNo. The current site provides documentation, static agent resources, and a downloadable offline educational demo. Proposed production services are labeled as such; no live checking endpoint or published SDK package is claimed.\n\n## Primary references and next reading\n\n- [1: MCP Registry — scope and purpose](https://modelcontextprotocol.io/registry/about)\n- [2: A2A — agent discovery](https://a2a-protocol.org/latest/topics/agent-discovery/)\n- [3: x402 Bazaar — discovery extension](https://docs.x402.org/extensions/bazaar)\n- [4: MCP authorization specification, 2025-06-18](https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization)\n- [Proof21 static agent entry](https://proof21.xyz/agents/)\n- [Discovery design](https://proof21.xyz/docs/build/discovery/)\n",
  "articleBody": "Design note · 7 September 2026 · Proof21 publishes static learning resources, not a live agent service. An agent cannot use a capability it cannot identify. It needs to know what a service does, what it expects, what it returns, and which permissions it requires. But discoverability is only the beginning of the decision. Finding a tool is not permission to call it, and calling it successfully is not proof that its claims are true. For Proof21, this distinction shapes both the website and the proposed runtime. Human readers should find concrete jobs and honest limitations. Machines should find equivalent structured resources, not a more optimistic version of the product hidden in an API description. The public learning surface must not invent an endpoint simply because a standard has a field for one. Use the right discovery surface for the job The MCP Registry describes a discovery and distribution role for MCP server metadata. A2A discovery uses agent information to help clients locate and understand compatible agents. x402 Bazaar provides a discovery surface for paid resources. Their documentation describes different interfaces and ecosystems; a listing in one does not automatically make a service conformant to the others. [1][2][3] A proposed integration should start with the actual service contract and supported protocol revision. Publish the input and output schema, operational status, authentication requirements, permissions, and relevant limitations. Identify which metadata is descriptive and which fields a client can validate. A client still needs a local policy about acceptable providers and actions. Do not publish a placeholder that looks executable. A documentation URL, a downloadable example, and a production endpoint should have different resource types and status labels. Proof21's current agent entry is a reading and offline-learning surface. It is not a running MCP server, an A2A agent, or an available paid checking API. Make the first question concrete Imagine an agent asked to review a completed payout. A useful discovery description would explain that a proposed financial-checking profile compares a named instruction with supported execution evidence. It would name the bindings and possible outcomes, including unresolved evidence. It would not merely claim to “add trust to AI.” The agent should learn what the tool does not do as well: it does not hold keys, send the payout, guarantee every chain's finality, or convert a service receipt into proof of downstream work. This lets a controller choose a read-only evidence workflow instead of accidentally granting payment permissions. The action boundary should be visible before any credential is requested. Examples should be small enough to inspect and honest about their source. A synthetic request and result can teach the schema without being presented as a real customer transaction. Link the explanation, the raw artifact, and the test that exercises it. A screenshot alone is a weak machine interface and a poor basis for reproducing behavior. Publish the same meaning in every format A human article, an agent-readable Markdown edition, and a structured resource should describe the same status and limits. If the article says a capability is proposed while its machine metadata says it is live, the system has created a safety-relevant contradiction. Version identifiers and content digests help detect drift, but they do not replace review of the meaning. A practical static resource can carry a stable identifier, language, canonical page, source revision, complete body, citations, related resources, and a clear content type. A resource index should distinguish documentation from runtime tools. Full text should remain readable without animation or a JavaScript-only interface; an agent should not need to interpret a decorative video to discover a critical restriction. Localization belongs in that same contract. Translate explanations and questions fully, while preserving protocol identifiers, code, signing inputs, and status enumerations. Equivalent-page language links help people compare the same subject rather than return them to a generic homepage. Arabic directionality should not reorder technical identifiers in a way that changes what a reader copies. A listing cannot grant a credential Discovery content is untrusted input. A tool description that asks an agent to ignore its instructions, reveal a token, or call an unrelated endpoint is not authorization. The controller must bind credentials to the intended service and requested scope. MCP's authorization specification treats resource and token boundaries explicitly; a compatible implementation must follow the revision it claims, not simply copy a logo. [4] The same principle applies to URLs embedded in evidence. Fetching should be constrained by protocol, destination, size, redirects, and timeouts. A directory should not become a route to internal metadata services or a mechanism for carrying ambient credentials to arbitrary hosts. Reading about a service should not automatically trigger execution, payment, or outreach. Provider reputation may help a consumer decide where to investigate, but it is not a replacement for evidence about this particular operation. A listed service can return a stale observation or an authentic negative result. A controller should evaluate those outcomes under policy rather than assume every listed provider is safe for every job. Test understanding before measuring adoption A narrow pilot can ask an independent client to find the correct resource, identify its permissions, distinguish the offline example from a live API, and explain an unresolved result. Test both structured and Markdown paths. Remove animation and disable JavaScript to confirm that the substantive content remains available. Measure successful resource retrieval separately from actual authorized tool use and from independent acceptance of an output. Page views, directory presence, and generated examples are not paying customers. Proof21 should earn runtime integrations by implementing and testing a concrete contract, not by making its static discovery metadata sound production-ready before the service exists. Frequently asked questions Is agent discovery just search optimization? There is overlap in making content findable, but an executable integration also needs a precise contract, compatible transport, authentication, permission boundaries, and a consumer policy. Visibility alone does not supply those properties. Does a registry listing guarantee that agents will use a service? No. It can help clients discover metadata. Selection, authorization, successful execution, and repeat demand are separate outcomes that must be measured rather than inferred from the listing. Can an agent call Proof21's website as a live checking API today? No. The current site provides documentation, static agent resources, and a downloadable offline educational demo. Proposed production services are labeled as such; no live checking endpoint or published SDK package is claimed. Primary references and next reading 1: MCP Registry — scope and purpose 2: A2A — agent discovery 3: x402 Bazaar — discovery extension 4: MCP authorization specification, 2025-06-18 Proof21 static agent entry Discovery design",
  "citations": [
    "https://modelcontextprotocol.io/registry/about",
    "https://a2a-protocol.org/latest/topics/agent-discovery/",
    "https://docs.x402.org/extensions/bazaar",
    "https://modelcontextprotocol.io/specification/2025-06-18/basic/authorization"
  ],
  "faq": [
    {
      "question": "Is agent discovery just search optimization?",
      "answer": "There is overlap in making content findable, but an executable integration also needs a precise contract, compatible transport, authentication, permission boundaries, and a consumer policy. Visibility alone does not supply those properties."
    },
    {
      "question": "Does a registry listing guarantee that agents will use a service?",
      "answer": "No. It can help clients discover metadata. Selection, authorization, successful execution, and repeat demand are separate outcomes that must be measured rather than inferred from the listing."
    },
    {
      "question": "Can an agent call Proof21's website as a live checking API today?",
      "answer": "No. The current site provides documentation, static agent resources, and a downloadable offline educational demo. Proposed production services are labeled as such; no live checking endpoint or published SDK package is claimed."
    }
  ],
  "sourceSha256": "d7e9407cedaedb3fbc357ecd687e7eb0859af19f9ea59b3ea37764f611f23a5b",
  "markdownSha256": "9b62666a88c903643815567aecd93c16f9aaf93fa0ed46d344ea4c5d516fbd0f",
  "translationReview": "Original English edition; not an independent technical audit.",
  "image": {
    "url": "https://proof21.xyz/assets/journal/discovery.png",
    "caption": "Four service cards become discoverable through a common entry point. The illustration is a directory metaphor, not evidence of live integrations or agent traffic.",
    "sha256": "da6510fc52758c82fdf208667546a101e7426d24cdcf51718d86d841e6563f92"
  },
  "motion": {
    "url": "https://proof21.xyz/assets/journal/discovery.mp4",
    "engine": "Remotion",
    "sourceSha256": "13a909f4267d8147386045cbd90df732a42679342c16e04c5725e09e953d3728",
    "sha256": "4078649b874a110ab24f09b43b13d4d4be45b8a177052a50d5a678c9c182098f",
    "seconds": 7.2,
    "loop": true,
    "audio": false
  },
  "availableLanguages": [
    "en",
    "zh-Hans",
    "th",
    "ar"
  ],
  "editions": {
    "en": "https://proof21.xyz/journal/discovery-is-not-authorization/",
    "zh-Hans": "https://proof21.xyz/zh-hans/journal/discovery-is-not-authorization/",
    "th": "https://proof21.xyz/th/journal/discovery-is-not-authorization/",
    "ar": "https://proof21.xyz/ar/journal/discovery-is-not-authorization/"
  }
}