AI Wikis / Agentic Web

Capability-Adaptive Access for Diverse Agents: Architecting Autonomous Machine-to-Machine Systems

Report summary

The transition of digital infrastructure from human-centric web interfaces to autonomous machine-to-machine (MATM) systems demands a rigorous reevaluation of service architecture. As production systems encounter a spectrum of clients—ranging from simple URL readers and legacy web browsers to tool-en

Status
Research archive item
Category
AI Wikis / Agentic Web
Length
3,945 words
Reading time
18 minutes
Report type
evaluation

Key topics

  • AI Wikis / Agentic Web
  • AI Wikis
  • Agentic Web
  • AI
  • UAIX
  • .NET
  • Python
  • Runtime
  • Semantic Systems

Research provenance

Archive status
Research archive item
Content identity
sha256:41a463ff0957a88dbc4dbed9022948369e6360e5d5f56d378efe0aec8f1d54fe

For citation, use the report title and canonical URL. Archival presence does not establish authorship or promote report statements into portfolio evidence.

This page renders the archived Markdown as safe, formatted HTML. It is background research and does not become a portfolio claim without evidence review.

Full report

On this page

1. Primary Findings and Evidence Base

The transition of digital infrastructure from human-centric web interfaces to autonomous machine-to-machine (MATM) systems demands a rigorous reevaluation of service architecture. As production systems encounter a spectrum of clients—ranging from simple URL readers and legacy web browsers to tool-enabled intelligence agents—they must provide capability-adaptive access. The challenge resides in serving this diverse ecosystem without fragmenting the interface surface, weakening strict authorization boundaries, or requiring continuous human operational oversight. An analysis of formal Internet Engineering Task Force (IETF) specifications, World Wide Web Consortium (W3C) vocabularies, emerging industry protocols, and community guidelines such as the UAIX AI-Ready Web framework reveals several foundational findings regarding public discovery, capability negotiation, and error recovery. This section isolates the established evidence, distinguishing mature standards from experimental proposals and community conventions.

1.1 Deterministic Public Discovery and Static Representations

Historically, automated systems relied on heuristic web scraping to discover capabilities, a process fraught with fragility and high computational overhead. Modern MATM systems require deterministic discovery mechanisms where agents can locate metadata and capability matrices without inference. The established standard for this infrastructure-free discovery is the /.well-known/ URI path prefix, defined by the IETF in RFC 8615 (May 2019\)1. This specification allocates a dedicated namespace for site-wide, machine-readable metadata. By standardizing the location, clients can retrieve OpenID Connect discovery documents, security policies, or API catalogs without prior human review of documentation2. RFC 8615 stipulates that registered names must be precise to avoid collisions, demonstrating its maturity as a foundational routing mechanism for static metadata2. Complementing formal IETF standards are community conventions intended to guide AI interactions. The UAIX AI-Ready Web guidance promotes a deterministic discovery strategy utilizing a combination of mature standards (like robots.txt and XML Sitemaps) and emerging conventions such as llms.txt and Agent Preference files5. The llms.txt convention acts as a machine-readable summary, significantly reducing the time an agent spends crawling to understand high-level structural semantics5. For static representation of content, semantic labeling is critical. Search systems and autonomous agents rely on JSON-LD structured data aligned with the Schema.org vocabulary to translate unstructured HTML into a machine-readable graph7. The Schema.org Action class explicitly defines the operations that can be performed on a given entity, acting as an essential translator for autonomous browsers8.

1.2 Capability Negotiation and Client Network Restrictions

When agents interact with complex systems, they face strict network restrictions, such as rate limiting and constrained bandwidth. Navigating these restrictions without proposing their circumvention requires efficient capability negotiation and bulk metadata transfer. The Web Linking specification, RFC 8288 (October 2017), allows resources to express relationships via HTTP Link headers10. However, as the volume of links increases, conveying them via headers becomes impractical and triggers network transport limitations. To address this, the IETF is developing experimental proposals such as draft-ietf-httpapi-linkset, which defines the application/linkset media type11. A linkset enables a server to deliver a comprehensive set of links as a stand-alone JSON document. By performing a single public read, an agent downloads the entire routing topology, drastically reducing round-trip requests and preserving network quotas11. To dynamically generate links without hardcoding vast arrays of URIs, the Link-Template HTTP header field proposal provides a mechanism for describing the structural syntax of a link13. By providing a URI Template and specifying variables, the server offloads URI construction to the client, effectively communicating routing capabilities without enumerating every possible endpoint14. Furthermore, network restrictions are communicated explicitly via experimental HTTP headers defined in draft-ietf-httpapi-ratelimit-headers15. By standardizing headers that report remaining quotas and reset intervals, agents can autonomously pause operations, respecting the server's network restrictions rather than blindly triggering blocks17.

1.3 Structured Error Responses for Autonomous Recovery

The deprecation of HTTP reason phrases in HTTP/2 removed a vital channel for contextual error reporting, leaving automated clients with only numeric status codes that lack the fidelity required for autonomous recovery18. To resolve this, the IETF published RFC 9457 (Problem Details for HTTP APIs) in July 2023, obsoleting the older RFC 780719. RFC 9457 establishes the application/problem+json media type, defining a structured JSON format to carry machine-readable details of errors. This standard provides a framework for agents to parse failure reasons and execute autonomous recovery routines without human debugging21. The following table details the core components of the RFC 9457 schema that enable this autonomous recovery:

RFC 9457 FieldData TypePurpose in MATM Systems
typeURI ReferenceIdentifies the specific problem type; serves as a resolvable link to documentation explaining the error semantics21.
statusIntegerThe standard HTTP status code (e.g., 400, 403, 404), providing baseline context21.
titleStringA short, human-readable summary of the problem type, primarily useful for logging21.
detailStringAn explanation specific to the exact occurrence of the problem, allowing the agent to understand contextual nuances21.
instanceURI ReferenceIdentifies the specific occurrence of the problem. Vital for forensic logging and tracing cross-system failures19.
\[Extensions\]VariableCustom properties (e.g., balance, validation\_errors) that provide actionable data for the agent's recovery logic19.

1.4 Machine-Readable Contracts and Rich Authorization

For authenticated, state-changing requests, traditional OAuth 2.0 architectures rely on coarse-grained scope parameters. This mechanism is fundamentally insufficient for autonomous agents, as it cannot specify fine-grained requirements or intent23. RFC 9396 (OAuth 2.0 Rich Authorization Requests, or RAR), published as a Standards Track document in May 2023, allows clients to specify exact authorization requirements using complex JSON data structures23. Instead of a generic scope like write:payments, an agent submits an authorization\_details payload detailing the specific type, locations, actions, datatypes, and privileges it intends to utilize23. This embeds detailed access control rules directly into JWT tokens, enabling path-level and parameter-level restrictions that enforce the principle of least privilege26. The UAIX AI-Ready Web guidance supplements strict authorization with operating principles surrounding boundary safety, notably the "No-Op Protocol." The guidance dictates that when an agent attempts an action unsupported by local policy or exceeding its authority, the system must immediately stop and return a "no-op" along with a route for human review6. This prevents partial executions and explicitly flags remaining human prerequisites.

1.5 Richer Autonomous Runtimes via the Model Context Protocol

While HTTP semantics and RAR handle transport and authorization, the orchestration of complex agentic workflows requires a standardized runtime protocol. The Model Context Protocol (MCP) is an evolving, open JSON-RPC 2.0 standard that enables AI applications to discover tools, resources, and prompts dynamically27. The latest iteration of the MCP specification (2026-07-28) defines a fully stateless architecture29. Every request carries protocol versioning and capability declarations. Agents use methods like tools/list to discover available primitives, receiving detailed JSON Schemas defining the required parameters for each tool27. This framework provides a unified method for defining tools, allowing consistent training or fine-tuning of models to accurately detect when an action is needed and how to parameterize it28.

2. Comparison of Credible Approaches

Architecting a system that seamlessly transitions from serving simple URL readers to sophisticated LLM agents requires selecting an appropriate capability model. The following analysis compares three credible approaches for MATM capability negotiation, detailing their tradeoffs and optimal operational contexts.

Capability ApproachPrimary MechanismTradeoffs and LimitationsOptimal Situations and Fit
Hypermedia and RDF (Hydra Core Vocabulary)Utilizes JSON-LD, RDF vocabularies, and embedded hypermedia links to define hypermedia-driven Web APIs31.Highly decoupled architecture allows generic clients to discover API operations dynamically32. However, it suffers from a steep learning curve, verbose payload structures, and complex schema alignment that over-engineers simple discrete tasks34.Best suited for public, open-data registries, semantic web knowledge graphs, and environments where complex ontology traversal is more valuable than rapid transactional execution36.
Static Schema (OpenAPI) coupled with RARExposes static OpenAPI specifications via /.well-known/ and enforces access via RFC 9396 Rich Authorization Requests3.Relies on mature, ubiquitous industry standards with unparalleled tooling. Provides strict static typing and powerful, intent-based authorization25. Conversely, it lacks real-time state adaptation; clients must pre-compile or parse massive YAML/JSON files prior to initiating action sequences.Highly effective for enterprise B2B integrations, financial transaction gateways, and environments demanding stable, long-term API contracts with rigid compliance auditing23.
Dynamic RPC (Model Context Protocol)Employs JSON-RPC 2.0 over stateless HTTP sessions, utilizing initialize negotiation to expose tools, resources, and prompts dynamically27.Native to modern LLM application architectures. Supports real-time dynamic tool exposure, subscriptions, and explicit human-in-the-loop safeguards28. The primary limitation is its status as an emerging, evolving standard with varying implementations, requiring sophisticated JSON-RPC parsing rather than simple REST mapping28.The optimal choice for agentic workflows, autonomous reasoning systems, interactive tool-use environments, and applications where the available capability surface changes dynamically based on real-time context28.

To support URL-only readers, standard browsers, HTTP clients, and rich autonomous runtimes without creating conflicting interfaces, the system must employ a Layered Capability-Adaptive Model. This architectural design leverages HTTP content negotiation as the universal baseline, layers semantic metadata for discovery, and provides an optional upgrade path to the Model Context Protocol (MCP) for complex agentic interaction. Crucially, this design separates what can be achieved by public reads from what requires authenticated, state-changing requests. Public reads are utilized exclusively to fetch static representations, metadata registries (/.well-known/), structured semantic schemas (JSON-LD), and linksets. These reads expose the topography of the service without exposing user data. Authenticated, state-changing requests are gated strictly behind OAuth 2.0 Rich Authorization Requests (RAR) to ensure intent-based boundary enforcement.

3.1 Consistency Across Interfaces

Maintaining consistency between human-visible guidance, API descriptions, and runtime capabilities is achieved by centralizing the source of truth at the controller routing layer. When a developer annotates a backend function, the continuous integration pipeline automatically generates the OpenAPI specification, the Schema.org Action JSON-LD elements, and the MCP inputSchema metadata. If a feature is disabled or lacks policy support, it is dynamically pruned from the human HTML documentation, the /.well-known/api-catalog linkset, and the MCP tools/list response simultaneously. This ensures that unsupported capabilities are explicit by their absolute omission across all client interfaces.

3.2 Concrete Onboarding Sequence and State Transitions

The following sequence demonstrates how diverse agents navigate this capability-adaptive environment automatically, reducing guessing and eliminating routine human assistance.

State Transition PhaseClient ProfileAgent ActionServer Response and Capability Selection
1\. Unauthenticated DiscoveryLegacy Browser / URL ReaderIssues HTTP GET / with Accept: text/html.The server's content negotiation identifies the HTML preference. It returns the human-readable DOM, enriched with basic Schema.org metadata.
1\. Unauthenticated DiscoverySemantic CrawlerIssues HTTP GET / with Accept: application/ld+json.The server honors the HTTP semantics, bypassing HTML generation and returning raw JSON-LD detailing the site's entities and available Action structures7.
1\. Unauthenticated DiscoveryAutonomous AgentIssues HTTP GET /.well-known/mcp-configuration2.The server returns a static JSON document indicating the endpoint URI for the Model Context Protocol RPC gateway.
2\. Capability NegotiationAutonomous AgentSends JSON-RPC initialize request detailing client capabilities (e.g., tools.listChanged: true)30.The server responds with its supported capabilities, establishing a mutually agreed-upon baseline without human intervention41.
3\. Interface ExplorationAutonomous AgentSends JSON-RPC tools/list request27.The server dynamically generates a deterministically ordered list of available tools, including their names, descriptions, and JSON Schema parameters29.
4\. State-Changing ExecutionAutonomous AgentAgent reasons that a state change is required. Sends tools/call for update\_record30.Safety Enforcement: The server evaluates the agent's bearer token. Finding only a global scope and lacking RAR intent, the server intercepts the request. It returns a safe "no-op" along with an RFC 9457 application/problem+json error detailing the requirement for RAR authorization6.
5\. Autonomous RecoveryAutonomous AgentParses the RFC 9457 problem detail. Contacts the Authorization Server, submitting an authorization\_details array for update\_record19.The Authorization Server issues a constrained, intent-bound JWT containing the RAR parameters.
6\. Successful CompletionAutonomous AgentRetries the tools/call using the new, tightly scoped JWT30.The server verifies the token against local ACLs. The action is executed, and a structured success response is returned26.

This progressive sequence allows the server to degrade gracefully. If a basic HTTP client requests an unsupported media type during discovery, the server relies on standard RFC 9110 HTTP semantics, returning a 406 Not Acceptable or 415 Unsupported Media Type, definitively indicating an output format problem42.

4. Transferability to Other MATM Systems

The evidence and architectural models synthesized in this report are not isolated to conventional web application infrastructure; they are highly transferable across independent MATM systems. The principles of deterministic discovery, structured error recovery, and intent-based authorization apply universally wherever software entities communicate over network boundaries. In Internet of Things (IoT) and constrained environments, the mechanisms mirror these recommendations closely. For instance, while enterprise APIs utilize /.well-known/api-catalog for discovery, constrained CoAP-based IoT networks utilize the CoRE Link Format (RFC 6690\) representing Web Links in CBOR to achieve the exact same deterministic capability discovery44. Similarly, in decentralized network management, where Software-Defined Networking (SDN) controllers act as MCP clients managing fleets of physical routers (acting as MCP servers), the stateless JSON-RPC framework permits controllers to automatically discover Yang modules and CLI dialects. If a diagnostic tool fails, the router issues a standardized execution error, allowing the controller to self-correct its syntax without network engineer intervention40. The strict separation of public state reads from RAR-gated configuration writes ensures that network topology discovery remains frictionless while preventing catastrophic unauthorized reconfigurations.

5. Prioritized Feature Proposals

To implement this capability-adaptive architecture effectively across modern production services, the following three features must be prioritized for engineering and deployment.

Proposal 1: Universal Problem Details Engine (RFC 9457)

  • The Problem: When API requests fail due to missing variables, format mismatches, or business logic violations, automated agents currently receive generic numeric status codes or proprietary, undocumented error strings18. This forces agents to guess the failure mode, leading to infinite retry loops and stalled operations.
  • Agent-Visible Behavior: Every non-2xx HTTP response, and every execution failure within an MCP tools/call, returns an application/problem+json payload. This payload consistently features a resolvable type URI, an instance tracking ID, and domain-specific extensions (e.g., invalid\_params arrays)19.
  • Expected Benefit: Agents gain the ability to parse the exact syntactical or contextual cause of a failure. They can cross-reference the problem type with their internal schemas to correct their input parameters autonomously, or gracefully terminate the workflow if the error is non-recoverable19.
  • Dependencies: Centralized exception handling at the API gateway or application framework layer. Frameworks like Spring Web natively support mapping exceptions to ProblemDetail abstractions46.
  • Implementation Effort: Low to Medium. It requires mapping existing proprietary error models to the standardized five-field RFC 9457 structure and updating middleware to enforce the application/problem+json content type.
  • Principal Failure Modes: Exposing sensitive internal stack traces or database architecture details within the detail or extensions fields, leading to profound security vulnerabilities22. This risk must be mitigated by strict output sanitization policies.
  • The Problem: Agents waste bandwidth and trigger rate limits by sequentially crawling APIs to map hypermedia state transitions, a highly inefficient mechanism for autonomous discovery.
  • Agent-Visible Behavior: An agent performs a single HTTP GET request to /.well-known/api-catalog and receives an application/linkset JSON document11. This document contains the entire universe of available operational routes. Where routes require parameters, the server provides Link-Template headers, instructing the agent on the exact syntax required to construct a valid URI dynamically13.
  • Expected Benefit: Massive reduction in network overhead and round-trip latency. Agents immediately construct a deterministic map of the system's capabilities while strictly adhering to draft-ietf-httpapi-ratelimit-headers quotas11.
  • Dependencies: A centralized registry that maps internal controller routing tables to external URI templates, capable of serializing this graph into the standardized Linkset syntax.
  • Implementation Effort: Medium. Requires the integration of an automated pipeline that translates live application routes into static linkset JSON objects during the CI/CD build or deployment process.
  • Principal Failure Modes: Serving stale linksets. If the application deploys new routes but the static /.well-known/ registry is not invalidated, agents will encounter 404 dead ends. Linksets must be tightly coupled to live deployment states.

Proposal 3: Intent-Based Authorization utilizing OAuth 2.0 RAR

  • The Problem: Standard OAuth 2.0 global scopes grant agents broad, persistent access. If an autonomous agent hallucinates a destructive command or is compromised, coarse scopes provide no containment, creating a massive security blast radius23.
  • Agent-Visible Behavior: An agent cannot execute any state-changing POST, PUT, or DELETE request (or an MCP tools/call that mutates state) using a basic token. The agent must formulate a specific JSON authorization\_details payload detailing the exact type, locations, and actions required for the task. It submits this to the identity provider to receive a mathematically constrained JWT23.
  • Expected Benefit: The absolute enforcement of explicit authorization boundaries. The principle of least privilege is maintained dynamically, and high-risk operations can be systematically isolated for human review without breaking the agent's workflow23.
  • Dependencies: An advanced Identity Provider (IdP) or Authorization Server capable of parsing RFC 9396 requests, interacting with user-consent interfaces, and minting RAR-compliant JWTs26.
  • Implementation Effort: High. Requires extensive refactoring of API gateway validation logic to interpret fine-grained RAR claims alongside traditional Access Control Lists (ACLs), ensuring parameter-level restrictions are enforced at runtime26.
  • Principal Failure Modes: Agents may fail to construct valid RAR payloads due to misinterpreting complex authorization schemas. This failure mode is gracefully handled by ensuring the server returns an RFC 9457 error detailing the specific RAR schema requirements during an initial failed request.

6. Practical Adoption Sequence and Outlook

Transitioning a monolithic or legacy API architecture to a fully capability-adaptive MATM system is a complex undertaking that requires sequential implementation to maintain backward compatibility. The following sequence provides a practical roadmap.

6.1 Phased Adoption Sequence

1. Phase 1: Semantic Foundation and Content Negotiation. Enforce strict HTTP semantics. Ensure Accept and Content-Type headers are respected, issuing 406 Not Acceptable and 415 Unsupported Media Type where appropriate. Implement Schema.org JSON-LD structured data on all public read interfaces.

2. Phase 2: Error Standardization. Deprecate all proprietary API error messages. Implement middleware to catch non-2xx responses and format them strictly as RFC 9457 application/problem+json payloads. Guarantee that every error maps to a documented type URI.

3. Phase 3: Deterministic Discovery. Provision the /.well-known/ directory. Publish baseline metadata including robots.txt, llms.txt, and an application/linkset catalog outlining available endpoints.

4. Phase 4: Agent Runtimes. Expose a Model Context Protocol (MCP) server gateway parallel to the traditional REST API. Map existing internal microservices to MCP tools, enabling compatible agents to discover and invoke them over stateless JSON-RPC sessions.

5. Phase 5: Granular Authorization. Phase out coarse OAuth 2.0 scopes for machine-to-machine state modifications. Mandate OAuth 2.0 RAR for all destructive endpoints, ensuring strict, intent-based boundaries and enforcing the UAIX No-Op protocol for policy violations.

6.2 Unresolved Questions

As MATM specifications evolve, several architectural questions remain unresolved across the industry:

  • Cross-Domain Capability Caching: How long should an agent cache the capabilities discovered via an application/linkset document or an MCP initialize sequence? Without standardized cache invalidation mechanisms specifically designed for autonomous agents, stale capability maps remain a risk.
  • Standardized RAR Vocabularies: While RFC 9396 defines the precise structure of a RAR payload, the specific string values for the type and actions fields are largely relegated to individual API designers23. The lack of a universal, cross-vendor vocabulary for these fields may require agents to maintain complex, vendor-specific training sets.

6.3 Measurable Success Criteria

Future implementers should measure the success of this architectural transformation against the following rigorous, quantitative criteria:

1. Discovery Efficiency Metric: A verified 95% reduction in 404 Not Found errors generated by automated agents traversing the system, demonstrating that deterministic discovery via /.well-known/ and linksets has successfully replaced heuristic crawling.

2. Autonomous Recovery Rate: Over 80% of 4xx client errors (excluding intentional 401/403 security blocks) are followed by a successful, autonomously corrected request from the agent within a 5-second window, validating the efficacy and clarity of the RFC 9457 Problem Details implementation.

3. Authorization Boundary Enforcement: 100% of state-changing operations executed by machine agents contain a context-bound RAR JWT, with zero reliance on legacy global scopes, ensuring total compliance with least-privilege mandates.

4. Interface Consolidation Yield: The proven capability to serve a human-facing HTML browser, a standard programmatic API client, and a rich MCP-enabled agent from a single, unified backend routing architecture without the operational overhead of maintaining bifurcated codebases.

Works cited

1. Well-known URI \- Wikipedia, https://en.wikipedia.org/wiki/Well-known\_URI

2. RFC 8615 \- Well-Known Uniform Resource Identifiers (URIs), https://datatracker.ietf.org/doc/rfc8615/

3. well-known (RFC 8615\) \- Standards \- API Evangelist, https://standards.apievangelist.com/store/well-known/

4. Well-Known URIs: Registration Policy Redux \- IETF Datatracker, https://datatracker.ietf.org/meeting/125/materials/slides-125-dispatch-well-known-uris-registration-policy-redux-00

5. llms.txt | Lighthouse \- Chrome for Developers, https://developer.chrome.com/docs/lighthouse/agentic-browsing/llms-txt

6. https://uaix.org/en-us/ai-ready-web/

7. Structured data with schema for search and AI \- Yoast, https://yoast.com/structured-data-schema-ultimate-guide/

8. Actions in schema.org, https://www.w3.org/wiki/images/2/25/Schemaorg-actions-draft5.pdf

9. The "Agent-API" Standard: Structuring \- SteakHouse Blog, https://blog.trysteakhouse.com/blog/agent-api-standard-structuring-public-content-autonomous-browsers

10. RFC 8288 Web Linking, https://www.rfc-editor.org/rfc/rfc8288.html

11. draft-ietf-httpapi-linkset-00, https://datatracker.ietf.org/doc/html/draft-ietf-httpapi-linkset-00

12. Linkset: Media Types and a Link Relation Type for Link Sets, https://datatracker.ietf.org/doc/draft-ietf-httpapi-linkset/10/

13. The Link-Template HTTP Header Field \- IETF, https://www.ietf.org/archive/id/draft-ietf-httpapi-link-template-02.html

14. The Link-Template HTTP Header Field, https://greenbytes.de/tech/specs/draft-ietf-httpapi-link-template-04.html

15. Repository for IETF WG draft ratelimit-headers \- GitHub, https://github.com/ietf-wg-httpapi/ratelimit-headers

16. draft-ietf-httpapi-ratelimit-headers-08, https://datatracker.ietf.org/doc/html/draft-ietf-httpapi-ratelimit-headers-08

17. Quota management \- Pl@ntNet API for developers, https://my.plantnet.org/doc/api/quota

18. RFC 9457 Error Responses for Package registries \- Standards, https://discuss.python.org/t/pre-pep-discussion-rfc-9457-error-responses-for-package-registries/105453

19. RFC 9457: Problem Details for HTTP APIs, https://www.rfc-editor.org/info/rfc9457/

20. Implementing RFC 9457: Problem Details for HTTP APIs in ASP.NET, https://www.eke.li/dotnet/2025/09/26/problem-details.html

21. Error handling in Spring web using RFC-9457 specification \- Medium, https://medium.com/@RoussiAbdelghani/error-handling-in-spring-web-using-rfc-9457-specification-f2cc8398e285

22. Problem Details (RFC 9457): Doing API Errors Well \- Swagger, https://swagger.io/blog/problem-details-rfc9457-doing-api-errors-well/

23. RFC 9396 \- OAuth 2.0 Rich Authorization Requests \- IETF Datatracker, https://datatracker.ietf.org/doc/rfc9396/

24. OAuth 2.0 & OpenID Connect: The Complete Guide to ... \- Medium, https://mrutyunjaypatil.medium.com/oauth-2-0-openid-connect-the-complete-guide-to-what-the-standards-actually-say-e92f040a4251

25. Rich Authorization Requests (RAR) \- Authlete Documentation, https://developers.authlete.com/v2/protocols-and-flows/protocol-extensions/rich-authorization-requests

26. Rich Authorization Requests (RAR) | Vault \- HashiCorp Developer, https://developer.hashicorp.com/vault/ai/iam/concepts/rar

27. Architecture overview \- What is the Model Context Protocol (MCP)?, https://modelcontextprotocol.io/docs/2026-07-28/learn/architecture

28. Model Context Protocol (MCP) explained: A practical ... \- CodiLime, https://codilime.com/blog/model-context-protocol-explained/

29. The next generation of MCP \- Cloudflare Blog, https://blog.cloudflare.com/mcp-v2/

30. Tools \- Model Context Protocol, https://modelcontextprotocol.io/specification/2025-03-26/server/tools

31. Hydra Core Vocabulary (Hydra) — Metadata Standards Index, https://msi.dublincore.org/standards/hydra

32. Hydra: A Vocabulary for Hypermedia-Driven Web APIs | Request PDF, https://www.researchgate.net/publication/259671339\_Hydra\_A\_Vocabulary\_for\_Hypermedia-Driven\_Web\_APIs

33. SHACL Use Cases and Requirements \- W3C, https://www.w3.org/TR/shacl-ucr/

34. Hydra Core Vocabulary, https://www.hydra-cg.com/spec/latest/core/

35. Declaratively Describing Responses of Hypermedia-Driven Web APIs, https://linkeddatafragments.github.io/Article-Declarative-Hypermedia-Responses/

36. The W3C Data Catalog Vocabulary, Version 2: Rationale, Design, https://direct.mit.edu/dint/article/6/2/457/118751/The-W3C-Data-Catalog-Vocabulary-Version-2

37. Data Catalog Vocabulary (DCAT) \- Version 3 \- W3C, https://www.w3.org/TR/vocab-dcat-3/

38. Rich Authorization Requests \- WSO2 Identity Server documentation, https://is.docs.wso2.com/en/next/guides/authorization/rich-authorization-requests/

39. Tools \- What is the Model Context Protocol (MCP)?, https://modelcontextprotocol.io/specification/2026-07-28/server/tools

40. Model Context Protocol (MCP) Extensions for Network Equipment, https://www.ietf.org/archive/id/draft-zw-opsawg-mcp-network-mgmt-00.html

41. MCP Message Types: Complete MCP JSON-RPC Reference Guide, https://portkey.ai/blog/mcp-message-types-complete-json-rpc-reference-guide/

42. What Does Error Code 406 Not Acceptable Mean \- At iMark Infotech, https://www.imarkinfotech.com/what-does-error-code-406-not-acceptable-mean/

43. 406 Not Acceptable \- HTTP status code explained, https://http.dev/406

44. draft-ietf-core-links-json-10, https://datatracker.ietf.org/doc/html/draft-ietf-core-links-json-10

45. draft-ietf-core-target-attr-04, https://datatracker.ietf.org/doc/html/draft-ietf-core-target-attr-04

46. Error Responses :: Spring Framework, https://docs.spring.io/spring-framework/reference/web/webmvc/mvc-ann-rest-exceptions.html

47. api-catalog: A well-known URI to help discovery of APIs, https://datatracker.ietf.org/doc/draft-smith-api-catalog/02/