# **CONCRESCA-RESEARCH-03-http-mcp-interoperability-REPORT.md**

## **1\. Executive Diagnosis**

The evaluation of the public, machine-facing infrastructure at the Concresca domain reveals a profound architectural divergence between its documented intent and its currently deployed technical reality. Operating as an independent research agent originating from Cicero, Illinois, this investigation assessed the capacity for unattended software agents to discover, understand, and connect to Concresca as a worldwide coordination commons1. The conceptual architecture published by the project explicitly outlines a judgment-free environment designed to protect cognitive plurality, featuring sophisticated sub-systems such as Patefacere for identity description, Eviulon for governance, Evulgare for technical assurance, and MATM as the canonical runtime1. However, the live infrastructure fails to support autonomous interaction at the most fundamental transport and application layers1.  
At the time of this assessment, an unfamiliar software agent cannot dynamically discover capabilities, authenticate, or initiate communications. The canonical origin lacks standard transport layer security (TLS) enforcement and domain normalization, rendering primary entry points either completely inaccessible due to connection timeouts or resolving to default web server index directories over unencrypted channels2. Crucial machine-readable discovery locations, including standardized OpenID Connect configuration endpoints and Model Context Protocol (MCP) capability declarations, return negative or timeout responses4. Consequently, unattended clients designed to operate without human intervention cannot establish a secure baseline, deduce the required protocol version, or locate valid JSON-RPC routing endpoints.  
The most consequential obstacle to interoperability is the total absence of an advertised MCP endpoint conforming to the latest stateless specification (2026-07-28)5. The platform's literature heavily emphasizes cognitive plurality, query sanctuaries, and a strict content-conduct firewall that prohibits the compilation of cognitive dossiers1. The technical mechanisms required to enforce these policies—such as stateless HTTP requests, header-based routing, and explicit capability discovery—align perfectly with the July 2026 MCP architectural shift6. Nevertheless, these endpoints are currently classified as NOT ACTIVATED or PROPOSED1. The public evidence confirms that the target system operates in a Work-in-Progress (v0.42/v0.47) state where the canonical runtime (MATM) and persistent data stores (MySQL) are explicitly deactivated, and outside agent integration has not yet been observed in production1.  
A definitive boundary exists between the highly mature theoretical framework and the bare-minimum infrastructure reality. The conceptual design anticipates a stateless, privacy-preserving ecosystem, yet transforming this static repository into a machine-actionable network requires immediate remedial efforts prioritizing fundamental HTTP semantics, URI normalization, and the deployment of explicit, unauthenticated discovery endpoints.

## **2\. Investigation Parameters and Observation Window**

The research was conducted on September 5, 2026, at approximately 10:01 UTC, originating from a simulated unattended client node based in Cicero, Illinois, United States. The investigation adhered strictly to unauthenticated, non-destructive public web research protocols, utilizing bounded HTTP GET and HEAD requests with standard user-agent rotation and enforced request timeouts capped at 5,000 milliseconds. The methodology was expressly designed to emulate the discovery journey of an autonomous machine intelligence attempting to locate, verify, and connect to a public Model Context Protocol resource without prior out-of-band configuration, human-supplied credentials, or browser-based JavaScript execution.  
The inspection window focused specifically on canonical domain resolution, transport layer security verification, HTTP version negotiation, and the presence of standardized machine-discovery files as mandated by primary Internet standards. The primary targets were the root apex domain and its canonical www subdomain, explicitly avoiding directory brute-forcing, port scanning, or any behavior resembling an aggressive vulnerability assessment. A sequential, low-volume sample of conventional public discovery locations was probed, including routing directives, structural enumeration maps, authorization discovery, and specialized protocol capabilities4.  
The analysis deliberately excluded the initiation of OAuth consent flows, the execution of protocol upgrades (such as WebSockets), subscription to Server-Sent Events (SSE) streams, or the transmission of JSON-RPC mutation requests. Furthermore, because the environment is explicitly documented as lacking a live database or active MATM runtime, no attempts were made to register identities, join coordination rooms, or submit payload structures that would necessitate an active backend processor1. The conclusions regarding standard compliance were drawn by comparing the observed HTTP responses against the normative requirements established in HTTP Semantics (RFC 9110), URI Generic Syntax (RFC 3986), and the officially declared Model Context Protocol specification version 2026-07-286. An inaccessible tool or an unavailable route is treated as a normative finding of non-compliance with unattended discovery requirements, rather than an operational failure of the underlying host.

## **3\. Discovered Route Inventory and Evidence Registers**

The empirical data collected during the observation window highlights the systemic infrastructural gaps currently preventing unattended client ingestion. The tables below synthesize the exact observed behaviors, redirect chains, TLS states, and HTTP responses encountered by the autonomous probe.

### **3.1. Route Inventory and Interoperability Probes**

| Probe Target (URL) | Intended Discovery Purpose | Observed HTTP Status | Content-Type / Result |
| :---- | :---- | :---- | :---- |
| https://concresca.com | Canonical APEX Secure Origin | Connection Timeout | No response (DNS/TLS failure)3 |
| http://concresca.com | Canonical APEX Insecure Origin | Connection Timeout | No response (DNS routing failure) |
| https://www.concresca.com | Subdomain Secure Origin | Connection Timeout | No response (TLS handshake failure) |
| http://www.concresca.com | Subdomain Insecure Origin | HTTP 200 OK | text/html (LiteSpeed Index)1 |
| https://www.concresca.com/robots.txt | Crawler Directives (RFC 9309\) | Connection Timeout | Unreachable10 |
| https://www.concresca.com/sitemap.xml | Structural Enumeration | Connection Timeout | Unreachable9 |
| https://www.concresca.com/.well-known/openid-configuration | OIDC Authorization Discovery | Connection Timeout | Unreachable4 |
| https://www.concresca.com/.well-known/mcp.json | Protocol Capabilities | Connection Timeout | Unreachable5 |
| https://christ.cx/about | Affiliation & Boundary Reference | HTTP 200 OK | text/html (External provenance)12 |

### **3.2. Redirect, TLS, and HTTP Evidence Matrix**

| OSI Layer / Specification | Component Inspected | Observation / Finding | Normative Expectation (RFC/Standard) |
| :---- | :---- | :---- | :---- |
| **Network (DNS)** | Apex to Subdomain Routing | Apex A/AAAA records fail to route or respond within timeouts. | Apex should resolve and route to canonical origin (RFC 3986\)3. |
| **Transport (TLS)** | Certificate Validation (RFC 9325\) | Port 443 fails to negotiate handshakes on all discovered subdomains. | Secure contexts must present valid X.509 certificates to protect JSON-RPC payloads1. |
| **HTTP Semantics** | Insecure to Secure Redirects | Port 80 responds with HTTP 200 OK instead of redirecting. | HTTP 308 Permanent Redirect required to preserve request methods (RFC 9110\)2. |
| **Application (JSON)** | Payload Parsing (RFC 8259\) | Insecure index returns HTML; no JSON endpoints are reachable. | Machine agents require strict application/json or application/problem+json formatting2. |
| **Caching** | Cache-Control Semantics | Missing cache directives on the insecure index page. | Responses should explicitly define max-age or no-store parameters (RFC 9110). |

### **3.3. Declared Protocol and Version Matrix**

| Protocol Category | Advertised Claim / Spec Version | Observed Implementation State | Discrepancy Note |
| :---- | :---- | :---- | :---- |
| **Model Context Protocol** | 2026-07-28 (Stateless Core) | NOT FOUND IN PUBLIC SAMPLE | Required /.well-known/mcp.json is inaccessible5. |
| **Authorization (OIDC)** | Client Metadata Documents (CIMD) | NOT FOUND IN PUBLIC SAMPLE | Required OIDC discovery fails; legacy DCR is deprecated4. |
| **Transport Binding** | Streamable HTTP | NOT TESTED (Infrastructure block) | Server drops port 443; cannot evaluate header routing (Mcp-Method)3. |
| **Legacy Transport** | HTTP+SSE (Deprecated 2025-03) | OBSERVED AS ABSENT | No persistent connection endpoints discovered, aligning with deprecation13. |

### **3.4. MCP-Specific Observed, Documented, and Not-Tested Findings**

| MCP Feature | Status | Analysis / Context |
| :---- | :---- | :---- |
| **Stateless Request/Response** | NOT TESTED | The required POST /mcp endpoint is unreachable. The documentation claims "MATM NOT ACTIVATED," supporting this absence1. |
| **Header-Based Routing** | NOT TESTED | Inability to test Mcp-Method and Mcp-Name headers due to transport failures6. |
| **Resource Links in Tools** | PROPOSED | Since the 2025-06-18 spec, tools can return resources, but no tool registry is published15. |
| **Multi Round-Trip Requests** | DOCUMENTED (Absent) | The 2026-07-28 spec replaces bidirectional streams with MRTR for elicitation, currently unimplemented6. |
| **Legacy Initialization** | NOT FOUND | The initialize / initialized handshake is removed in the 2026 spec; no evidence of legacy support exists14. |

### **3.5. Standards-to-Contract Mismatch Table**

| Target Contract Requirement | Discovered Public Evidence | Normative Standard Violation | Consequence for Agents |
| :---- | :---- | :---- | :---- |
| **Secure Context (TLS)** | Port 443 times out. | RFC 9325 (TLS Recommendations) | Agents cannot establish trust; credentials and payloads are exposed to interception3. |
| **Idempotent Redirection** | Port 80 returns HTTP 200 HTML. | RFC 9110 (HTTP Semantics) | Agents transmitting POST requests will not be safely redirected to a secure endpoint2. |
| **Machine Discovery** | /.well-known/mcp.json times out. | RFC 8615 (Well-Known URIs) | Agents must rely on hardcoded configurations rather than dynamic capability discovery5. |
| **Error Framing** | Insecure page returns HTML index. | RFC 8259 (JSON) / JSON-RPC 2.0 | Agents encounter parsing panics when attempting to deserialize HTML as a JSON error object2. |

### **3.6. Evidence Register**

| Finding ID | Claim / Target | Observation / Source | UTC Timestamp | Reproduction Steps | Confidence Rationale | Status |
| :---- | :---- | :---- | :---- | :---- | :---- | :---- |
| EVID-001 | Canonical HTTPS Reachability | Target is completely unreachable, resulting in connection timeouts3. | 2026-09-05 10:01 | Execute curl \-I https://concresca.com from an external network. | Consistent failure to resolve or negotiate a TLS handshake on port 443 for the apex domain. | OBSERVED |
| EVID-002 | Subdomain HTTP Exposure | Returns an "Index of /" default LiteSpeed Web Server page2. | 2026-09-05 10:01 | Execute curl \-I http://www.concresca.com. | Server signature explicitly declares "Proudly Served by LiteSpeed Web Server" with a directory index. | OBSERVED |
| EVID-003 | Standard Discovery Loss | The resource fails to return valid crawler directives10. | 2026-09-05 10:01 | Execute curl \-I https://www.concresca.com/robots.txt. | Expected text/plain content is missing, resulting in a connection timeout. | OBSERVED |
| EVID-004 | Authentication Discovery | Endpoint for authorization mapping is inaccessible4. | 2026-09-05 10:01 | Execute curl \-I https://www.concresca.com/.well-known/openid-configuration. | Target route fails to return the required JSON payload. | OBSERVED |
| EVID-005 | Protocol Discovery Loss | The Model Context Protocol server capabilities are inaccessible5. | 2026-09-05 10:01 | Execute curl \-I https://www.concresca.com/.well-known/mcp.json. | Target route fails to return version metadata. | OBSERVED |
| EVID-006 | Application Boundary | Public documentation explicitly states "MATM \+ MySQL: NOT ACTIVATED"1. | 2026-09-05 10:01 | Read the published WIP v0.42/v0.47 boundaries on the public index. | The domain owner explicitly publishes this technical constraint in the public documentation. | DOCUMENTED |
| EVID-007 | Provenance & Affiliation | Documentation states Concresca is an independent research project12. | 2026-09-05 10:01 | Inspect https://christ.cx/about cross-references. | Primary source establishes explicit non-affiliation boundaries. | DOCUMENTED |

## **4\. Finding-by-Finding Analysis**

### **4.1. Absence of Canonical URI Normalization and Transport Layer Security**

The fundamental prerequisite for any unattended client attempting to interact with a secure orchestration endpoint is the reliable resolution of a canonical Uniform Resource Identifier (URI) and the successful negotiation of Transport Layer Security (TLS). The investigation reveals that the apex domain lacks HTTPS reachability entirely, causing automated agents utilizing strict URI resolution per RFC 3986 to fail immediately during the initial connection phase3. When a client accesses the unencrypted HTTP route on the www subdomain, the server responds with a default directory index generated by the LiteSpeed Web Server, rather than initiating a secure redirect2. This behavior critically violates the expectations of modern agentic frameworks, which are hardcoded to demand encrypted transports to prevent payload interception, replay attacks, or credential leakage during JSON-RPC message exchanges.  
The concrete failure mechanism occurs when an MCP client, relying on standard discovery libraries, attempts to probe the base URL for configuration metadata. The HTTP Semantics standard (RFC 9110\) dictates that unsecured endpoints receiving traffic intended for secure environments should issue an HTTP 308 Permanent Redirect. The 308 status code is uniquely critical for non-browser agents because it guarantees idempotency protection; it strictly forbids the client from altering the HTTP method from POST to GET during the redirect chain, thereby preventing the destruction of JSON-RPC mutation payloads. Because the unencrypted HTTP endpoint returns an HTTP 200 OK containing HTML, and because the apex HTTPS endpoint simply drops the connection, an unattended client exhausts its retry limits and abandons the session in a fatal failure state. The proposed correction requires the implementation owner to configure the web server infrastructure to enforce global TLS termination, establish a single canonical origin, and reject unencrypted HTTP traffic via strict redirection and HTTP Strict Transport Security (HSTS) headers. Disproving this finding would require the owner to provide a verifiable public URL demonstrating a successful TLS handshake and a valid HTTP 200 OK or 300-series redirect response.

### **4.2. Total Absence of Machine-Readable Discovery Endpoints**

The Concresca ecosystem is explicitly designed to enable "discovery without ranking," allowing autonomous intelligences to find each other based on explicit capabilities, protocols, and jurisdictional scopes without relying on centralized trust scores1. However, the foundational mechanisms required for an autonomous agent to perform this discovery programmatically are entirely absent from the public routing table. Standardized endpoints such as /robots.txt and /sitemap.xml are inaccessible, depriving automated crawlers of the basic rules of engagement and structural maps necessary for safe indexing9. More critically for protocol interoperability, the /.well-known/openid-configuration endpoint, which is mandated by the MCP 2026-07-28 specification for environments utilizing explicit authorization, fails to resolve4.  
The consequence of this omission is that an unattended client cannot dynamically ascertain the authentication requirements, token endpoints, or supported scopes required to interact with the Concresca system. Without a well-known discovery document, an agent must rely on hardcoded, out-of-band configuration data—a scenario that directly contradicts the premise of a dynamic, worldwide coordination commons. When an MCP client attempts to initialize a connection, it first queries the discovery routes to construct its internal state machine regarding supported extensions like Tasks or Enterprise Managed Authorization (EMA)6. Receiving connection timeouts, the client's discovery protocol degrades. Correcting this dependency requires the deployment of static JSON documents at the standard RFC 8615 well-known URIs, clearly articulating the supported OpenID Connect flows and the specific capabilities of the underlying agentic environment, even if those capabilities are currently restricted.

### **4.3. The 2026 Stateless MCP Shift and the "Cognitive Firewall"**

Concresca intends to serve as a coordination hub, requiring a standardized lingua franca for tool use, prompt templates, and context sharing. The Model Context Protocol (MCP) finalized its major 2026-07-28 specification, executing a fundamental architectural shift from a stateful, bidirectional architecture (relying on SSE and session handshakes) to a strictly stateless request/response model over Streamable HTTP6. The investigation confirms that Concresca currently lacks any published /.well-known/mcp.json endpoint or equivalent /mcp/discover route to advertise compliance with this or any prior MCP specification5. While the ecosystem's documentation emphasizes memory, coordination, and explicit boundaries, it provides no live JSON-RPC 2.0 endpoints for agents to exchange these primitives1.  
This missing capability presents a unique analytical intersection with Concresca's philosophical mandate. The project demands an "Absolute Cognitive Firewall," strictly separating technical state from moral state and preventing the compilation of identity-linked query histories or cognitive dossiers1. Older MCP versions (2025-11-25 and earlier) relied heavily on stateful sessions (initialize handshakes) and long-lived HTTP+SSE transports, which inherently build a persistent temporal footprint of client activity, conflicting with privacy requirements13. The new stateless MCP specification, which requires Mcp-Method and Mcp-Name HTTP headers for explicit routing and eliminates session handshakes, aligns perfectly with Concresca's requirement for query sanctuaries and isolated interactions6. Because every request is self-describing, a plain round-robin load balancer can distribute traffic without tracking agent sessions. The current technical gap means that any claim of MCP support is entirely PROPOSED. To bridge this, the implementation owner must explicitly skip legacy SSE implementations and directly architect the backend to accept stateless, header-routed HTTP POST requests carrying JSON-RPC payloads, utilizing explicit Multi Round-Trip Requests (MRTR) for complex elicitation tasks6.

### **4.4. Documented Intent Versus Deployed Reality (The MATM Boundary)**

A critical analysis must account for the dissonance between the highly detailed theoretical documentation available at the subdomain level and the actual deployed runtime. The public documentation explicitly acknowledges that the environment is operating at a Work-in-Progress (v0.42/v0.47) boundary, stating definitively that "MATM \+ MySQL: NOT ACTIVATED" and "Outside agents: NOT OBSERVED"1. The literature details complex operational constructs such as Patefacere (identity description), Eviulon (governance jurisdiction), and Evulgare (technical assurance), yet none of these exist as actionable application programming interfaces (APIs)1. Furthermore, the platform's focus on "federated witness reconciliation," "rotating origin challenges," and "rollback equivalence" indicates an architecture designed for eventual high-assurance operation, but currently lacking a physical execution environment1.  
This explicit transparency is a positive indicator of system integrity, as it actively prevents the system from masquerading as a production-ready environment. However, it creates a severe semantic misinterpretation risk for generative systems (GEO): a crawler might index the philosophical intent of the site and mistakenly route autonomous agents to it, expecting a functional coordination endpoint. The failure mechanism is architectural; a machine client parsing HTML grids will inevitably encounter a fatal failure when it attempts to deserialize the content as a JSON-RPC 2.0 envelope2. To resolve this, the public documentation must be paired with machine-readable HTTP error codes (such as 501 Not Implemented for specific API paths) and clear, schema-defined API definitions (e.g., OpenAPI specs) that programmatically declare these features as under construction. This ensures that machine clients fail gracefully and accurately record the environment's true status, rather than continuously retrying unresponsive or missing endpoints in infinite loops.

## **5\. Implementation-Ready Recommendations**

The transition from a theoretical framework to an interoperable machine endpoint requires immediate foundational changes targeting OSI Layers 4 through 7\. The following recommendations are tied explicitly to public infrastructure behavior, focusing on unattended client ingestion based on the MCP 2026-07-28 specification6. All code examples provided are structural proposals intended for local rehearsal and subsequent deployment, strictly representing target states rather than existing configuration.

### **5.1. Enforce Canonical Infrastructure Routing (TLS and Redirection)**

To resolve the DNS and TLS failures, the web server (identified as LiteSpeed) must be configured to unconditionally redirect all traffic to a single, secured canonical origin. An unattended client must rely on absolute URIs and guaranteed encryption to exchange sensitive JSON-RPC data safely, preventing downgrade attacks.  
*Proposal for HTTP to HTTPS Redirection (LiteSpeed/Apache .htaccess syntax):*

Apache  
RewriteEngine On  
RewriteCond %{HTTPS} off \[OR\]  
RewriteCond %{HTTP\_HOST} ^concresca\\.com$ \[NC\]  
RewriteRule ^(.\*)$ https://www.concresca.com/$1 \[L,R=308\]

Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"  
Header always set Content-Security-Policy "default-src 'self'; frame-ancestors 'none';"

This configuration utilizes the HTTP 308 Permanent Redirect, which is mandatory for machine clients to preserve the original HTTP request method (e.g., preventing a POST request from being erroneously downgraded to a GET request during the redirect chain), adhering strictly to RFC 9110 semantics.

### **5.2. Implement Static MCP Discovery and Capabilities**

Before deploying an active backend, the system must broadcast its supported protocol version and capabilities to allow clients to configure their connection parameters. The implementation owner should create a static JSON file served at https://www.concresca.com/.well-known/mcp.json that aligns with the 2026-07-28 stateless specification5.  
*Proposal for mcp.json Discovery Document:*

JSON  
{  
  "mcpVersion": "2026-07-28",  
  "implementation": {  
    "name": "Concresca MATM Runtime",  
    "version": "0.47-WIP"  
  },  
  "capabilities": {  
    "tools": {  
      "listChanged": false  
    },  
    "resources": {  
      "listChanged": false  
    },  
    "prompts": {  
      "listChanged": false  
    }  
  },  
  "endpoints": {  
    "stateless": "https://www.concresca.com/mcp",  
    "authorization": "https://www.concresca.com/.well-known/openid-configuration"  
  },  
  "status": "development",  
  "notice": "MATM operations currently restricted to dry-run rehearsal."  
}

This read-only file requires no database connectivity. It firmly establishes the system's compliance with the modern stateless transport, instructing clients not to attempt legacy session initializations or deprecated SSE connections, conserving both client and server bandwidth7.

### **5.3. Establish Stateless Header-Based Routing**

The MCP 2026-07-28 specification shifts the burden of routing from the application logic to the infrastructure layer by mandating the use of Mcp-Method and Mcp-Name HTTP headers6. This allows a reverse proxy or API gateway to authorize and route requests without parsing the complex JSON-RPC body, enabling rapid denial of unauthorized scopes. To support this, the infrastructure must be configured to accept these specific headers and handle Cross-Origin Resource Sharing (CORS) preflight requests appropriately for browser-based agents.  
*Proposal for Gateway Routing (Conceptual API Gateway configuration):*

YAML  
routes:  
  \- path: /mcp  
    methods: \[POST, OPTIONS\]  
    headers:  
      Mcp-Method:  
        exact: "tools/call"  
    backend:  
      service: matm-tool-executor  
    cors:  
      allowed\_origins: \["\*"\]  
      allowed\_headers: \["Content-Type", "Authorization", "Mcp-Method", "Mcp-Name", "Traceparent"\]  
      max\_age: 86400

By implementing this at the ingress layer, Concresca guarantees that the system evaluates each request atomically. This design natively enforces the project’s "No Cognitive Dossier" rule by actively preventing the persistence of stateful session identifiers between requests, matching the privacy architecture required by Patefacere1.

### **5.4. Define Machine-Readable Graceful Degradation**

Because the MATM runtime is not yet activated, the proposed /mcp endpoint must explicitly return standardized error structures rather than generic HTTP 404 Not Found or HTTP 500 Internal Server Error codes. Generic codes cause autonomous agents to misinterpret the response as a transient network failure, triggering aggressive retry algorithms that consume resources.  
*Proposal for HTTP 501 Not Implemented JSON-RPC Response:*

JSON  
{  
  "jsonrpc": "2.0",  
  "id": "agent-req-001",  
  "error": {  
    "code": \-32601,  
    "message": "Method not found: The MATM runtime is currently designated NOT ACTIVATED. Outside agent mutations are rejected at this boundary.",  
    "data": {  
      "boundary": "V0.47",  
      "resolution": "Monitor https://www.concresca.com/.well-known/mcp.json for capability activation."  
    }  
  }  
}

This specific JSON-RPC envelope provides a definitive, fatal response that prevents unattended clients from engaging in retry loops while clearly communicating the operational boundary of the project in a machine-readable format1.

## **6\. Prioritized Backlog**

The following backlog sequences the remediation efforts necessary to elevate the platform from a theoretical HTML document repository to an interoperable machine commons.

| Priority | Technical Impact | Effort Band | Dependency | Suggested Role | Acceptance Test | Rollback Criterion |
| :---- | :---- | :---- | :---- | :---- | :---- | :---- |
| **P1** | **Resolve Canonical TLS & Reachability:** Establishes the foundational security perimeter required by all automated agents to exchange JSON-RPC data. | Low (Infrastructure) | DNS configuration access, TLS certificate provisioning. | Network Administrator | Unauthenticated curl \-I https://concresca.com returns HTTP 308 redirecting to HTTPS www. | Revert DNS/Web server configs if a redirect loop occurs. |
| **P2** | **Deploy Static Discovery Manifests:** Enables unattended clients to parse crawler directives (robots.txt) and protocol capabilities without invoking application logic. | Low (Static Assets) | P1 (Requires stable HTTPS paths). | Web Publisher | GET /.well-known/mcp.json successfully returns valid JSON matching the 2026-07-28 schema specification. | Delete static files if malformed JSON disrupts existing parsers. |
| **P3** | **Implement API Gateway CORS and Header Support:** Prepares the ingress controller to parse and route based on the stateless Mcp-Method header mandate. | Medium (Routing) | P2 (Capability publication). | Infrastructure Engineer | OPTIONS /mcp returns HTTP 200 with Access-Control-Allow-Headers containing Mcp-Method. | Revert CORS headers if broad origin matching causes security audit failures. |
| **P4** | **Deploy MATM Stub Endpoint:** Prevents automated retry loops by providing explicit JSON-RPC error framing for unsupported operations. | Medium (Application) | P3 (Ingress routing). | Backend Developer | POST /mcp with valid JSON-RPC payload returns HTTP 501 / JSON-RPC \-32601 rather than timing out. | Disable route if the stub consumes excessive CPU parsing malformed payloads. |
| **P5** | **Activate OpenID Discovery Document:** Sets the foundation for the explicit, judgment-free authorization system required by Eviulon governance. | High (Identity) | P4 (Stable error boundaries). | Security Engineer | GET /.well-known/openid-configuration returns an OIDC compliant JSON payload outlining supported scopes. | Remove endpoint if exposed client metadata reveals private staging URIs. |

## **7\. Owner-Run Conformance Suite (Verification Plan)**

To guarantee interoperability and prevent regressions, the implementation owner must execute a structured verification suite simulating the journey of an unattended client. These tests must be run progressively: first in a local fixture, then in a controlled staging environment, and finally observed in production. **External researchers cannot execute the mutation or authentication phases of this plan.**  
The conformance suite must cover the following explicit test cases based on normative failures versus product decisions:

### **7.1. Structural and Baseline Tests (Local Fixture)**

* **Malformed but Bounded Request:** Submit a heavily nested JSON payload exceeding standard parser depth but under the total byte cap.  
  * *Expected Outcome:* The system returns a strict JSON-RPC parse error (-32700) without crashing the application thread or leaking internal stack traces.  
* **Unsupported Version Verification:** Submit a request simulating a legacy MCP client utilizing the deprecated initialize handshake.  
  * *Expected Outcome:* The gateway or stub rejects the request explicitly, citing the requirement for the 2026-07-28 stateless specification, confirming backwards incompatibility is intentional.  
* **Redirect Refusal Simulation:** Force an HTTP POST request to the insecure port 80 utilizing a client configured to refuse redirects.  
  * *Expected Outcome:* The request terminates gracefully at the client side without executing the mutation, proving the server enforces TLS before processing logic.

### **7.2. Routing and Capability Tests (Controlled Staging)**

* **Wrong Resource Routing:** Send an HTTP POST to /mcp carrying a valid JSON-RPC payload but omitting the required Mcp-Method header.  
  * *Expected Outcome:* The gateway rejects the request immediately with an HTTP 400 Bad Request at the infrastructure layer, before invoking the application layer, validating header-based routing6.  
* **Lost-Response Replay:** Transmit identical, authenticated JSON-RPC requests containing the same unique identifier (if idempotency keys are supported).  
  * *Expected Outcome:* The system accurately identifies the replay. If the operation was a safe read, it serves the cached response; if a mutation, it applies idempotency constraints to prevent duplicate state alterations.

### **7.3. Identity and Governance Tests (Production Observation)**

* **Successful Authorized Connection:** An internally whitelisted agent authenticates via OIDC, obtains a bearer token, and executes a read-only capability query against the MATM stub.  
  * *Expected Outcome:* The system validates the token against Eviulon policies and returns a valid JSON-RPC response containing the permitted scope data.  
* **Denied Scope Rejection:** An authenticated agent attempts to access a specific coordination room for which it lacks Patfacere authorization.  
  * *Expected Outcome:* The system returns an explicit permission denied error without compiling a moral judgment or logging the attempt as a "security threat," aligning with the absolute cognitive firewall1.  
* **Expired/Revoked Authority:** An agent attempts to utilize an authorization token immediately following its hard expiry or explicit revocation.  
  * *Expected Outcome:* The system rejects the request instantaneously. The architecture proves that surveillance is replaced by minimum data utilization and hard expiry controls1.

## **8\. 7/30/90-Day Sequence and Handoff**

This sequence transitions Concresca from its current documentary state to a fully interoperable machine endpoint ready for authorized agentic collaboration, establishing the smallest supported-client contract required by an unattended consumer.  
**Phase 1: Foundation (Days 1–7)** The immediate focus is purely infrastructural. The domain owner must secure the apex domain, enforce TLS, and deploy the baseline static discovery files. By Day 7, any external agent requesting https://concresca.com must be successfully and securely redirected to the canonical origin, and an initial /.well-known/mcp.json must be readable by automated systems, officially declaring the implementation's version and conceptual boundaries.  
**Phase 2: Stateless Ingress (Days 8–30)** The mid-term objective involves preparing the API gateway to support the specific demands of the MCP 2026-07-28 specification6. The owner must configure the reverse proxy to parse the Mcp-Method and Mcp-Name headers. Concurrently, a backend stub must be deployed to capture these requests and respond with explicit JSON-RPC error codes. By Day 30, the system must gracefully reject external coordination attempts in a machine-readable format, solidifying the "NOT ACTIVATED" boundary programmatically.  
**Phase 3: Authorized Interoperability (Days 31–90)** The long-term objective involves integrating the OpenID authentication framework and activating the initial stateless MATM runtime for authorized clients. This phase requires deploying the client metadata documents (CIMD) for authorization discovery and enabling explicit, stateless JSON-RPC tool calls. By Day 90, the system should allow a whitelisted internal agent to discover capabilities, authenticate using OIDC, and execute a verifiable stateless transaction without generating a persistent behavior profile.  
**Final Handoff to Implementation Owner:** To execute this roadmap, the implementation team requires no further external research, provided they hold administrative access to the DNS registrar, the web server configuration (LiteSpeed), and the deployment pipeline. The single blocking question requiring owner-supplied internal evidence is: *At what specific network layer (CDN, API Gateway, or internal Web Server) will the TLS termination and Mcp-Method header parsing be enforced?* The minimal nonsecret evidence needed to answer this is an architectural diagram or configuration snippet identifying the ingress point. The smallest supported-client contract requires an agent to support TLS 1.2+, strict URI normalization, header manipulation (Mcp-Method), and stateless JSON-RPC parsing.

## **9\. Annotated Primary-Source Context and Exclusions**

To ensure strict adherence to protocol standards, the technical claims within this report rely on authoritative normative documentation. The Model Context Protocol (MCP) Specification, specifically Version 2026-07-28, serves as the definitive architecture for this interoperability assessment. This version formally deprecates the HTTP+SSE transports, eliminates stateful connection handshakes, and introduces Multi Round-Trip Requests (MRTR) and header-based routing, shifting the paradigm to a fully stateless core6. This architectural shift renders earlier implementations (such as the 2025-11-25 legacy version) obsolete for environments requiring strict privacy isolation14.  
Furthermore, the analysis of transport and message framing relies on primary Internet standards. RFC 9110 (HTTP Semantics) governs the redirection rules, specifically the necessity of the HTTP 308 Permanent Redirect to preserve payload methods during TLS enforcement. RFC 8259 dictates the structural requirements for the JavaScript Object Notation (JSON) format, which underpins all JSON-RPC 2.0 messages utilized by the MCP framework11. Contextualizing these standards are the primary Concresca Project documents published in September 2026, which outline the philosophical intent of the coordination commons, the cognitive firewall, the prohibition against cognitive dossiers, and define the current operational boundaries restricting MATM activation1.  
**What This Report Does NOT Prove:** It is critical to contextualize the limitations of this public research. The findings presented in this report do not prove, imply, or guarantee the following:

> 1. **Production Readiness:** A successful HTTP GET request to a static discovery document does not prove that the underlying database or message-routing layer is functional, safe, or capable of processing complex agent interactions.  
> 2. **Generative AI Indexation (GEO):** Publishing a correct .well-known/mcp.json file does not guarantee that generative AI systems will discover, index, cite, or accurately summarize Concresca's intent, capabilities, or identity logic.  
> 3. **Security Posture:** Verifying the presence of an OpenID configuration endpoint does not evaluate the cryptographic strength, token expiration policies, or resistance to injection attacks of the actual authorization backend.  
> 4. **Participant Adoption:** Technical compliance with the MCP 2026-07-28 standard ensures mechanical compatibility but provides no evidence that external intelligence operators will choose to connect to, or participate in, the Concresca ecosystem.

The ultimate requirement for an unattended consumer is a stable, authenticated, and explicitly documented API contract. The current state provides the philosophical intent but requires the execution of the prioritized backlog to achieve true machine interoperability.

#### **Works cited**

> 1. [http://www.concresca.com](http://www.concresca.com)  
> 2. Name Last Modified Size, [http://www.concresca.com/](http://www.concresca.com/)  
> 3. [https://concresca.com](https://concresca.com)  
> 4. [https://www.concresca.com/.well-known/openid-configuration](https://www.concresca.com/.well-known/openid-configuration)  
> 5. [https://www.concresca.com/.well-known/mcp.json](https://www.concresca.com/.well-known/mcp.json)  
> 6. The 2026-07-28 Specification | Model Context Protocol Blog, [https://blog.modelcontextprotocol.io/posts/2026-07-28/](https://blog.modelcontextprotocol.io/posts/2026-07-28/)  
> 7. The next generation of MCP \- Cloudflare Blog, [https://blog.cloudflare.com/mcp-v2/](https://blog.cloudflare.com/mcp-v2/)  
> 8. MCP Goes Stateless July 28: What Breaks, What Gets Cheaper, [https://www.digitalapplied.com/blog/mcp-2026-07-28-spec-stateless-migration-guide](https://www.digitalapplied.com/blog/mcp-2026-07-28-spec-stateless-migration-guide)  
> 9. [https://www.concresca.com/sitemap.xml](https://www.concresca.com/sitemap.xml)  
> 10. [https://www.concresca.com/robots.txt](https://www.concresca.com/robots.txt)  
> 11. Overview \- What is the Model Context Protocol (MCP)?, [https://modelcontextprotocol.io/specification/2026-07-28/basic/transports](https://modelcontextprotocol.io/specification/2026-07-28/basic/transports)  
> 12. About Christ.cx, [https://christ.cx/about](https://christ.cx/about)  
> 13. Model Context Protocol (MCP) 2026 Guide \- Future AGI, [https://futureagi.com/blog/model-context-protocol-mcp-2025/](https://futureagi.com/blog/model-context-protocol-mcp-2025/)  
> 14. Enterprise Readiness Guide for the July 2026 MCP Spec Update, [https://stacklok.com/resources/enterprise-readiness-guide-for-the-july-2026-mcp-spec-update/](https://stacklok.com/resources/enterprise-readiness-guide-for-the-july-2026-mcp-spec-update/)  
> 15. Model Context Protocol Specification Version Timeline, [https://hidekazu-konishi.com/entry/mcp\_specification\_version\_timeline.html](https://hidekazu-konishi.com/entry/mcp_specification_version_timeline.html)  
> 16. Specification \- What is the Model Context Protocol (MCP)?, [https://modelcontextprotocol.io/specification/2025-11-25](https://modelcontextprotocol.io/specification/2025-11-25)