altar

### **Final Review of the Altar Protocol Specification v1.0 Candidate**

This version of the Altar specification is a significant achievement. It has successfully integrated all critical feedback into a cohesive, secure, and developer-friendly design. It is, by all measures, **finished and ready for implementation.**

#### Confirmation: How All Feedback Was Addressed Correctly

*   ✅ **Developer Experience (Agility vs. Rigidity) -> SOLVED**: The introduction of dual `HostMode` (`STRICT` for production, `DEVELOPMENT` for iteration) is the ideal solution. It provides a secure-by-default posture while giving developers the fast feedback loop they need. The inclusion of a separate `RegisterTools` RPC just for this mode is clean and explicit.

*   ✅ **Runtime Bootstrap Discovery -> SOLVED**: The `GetAvailableContracts` RPC and the corresponding `Announce` -> `Discover` -> `Fulfill` workflow are now clearly defined. This closes the logical gap perfectly and makes the system self-describing for new Runtimes.

*   ✅ **Protocol & Schema Refinements -> SOLVED**:
    *   **Idempotency**: The role of `invocation_id` as a client-generated key for idempotency is now explicitly documented in the IDL comments and requirements.
    *   **Correlation**: The `correlation_id` has been promoted to a first-class citizen in `ToolCall` and `ToolResult`, ensuring end-to-end tracing is a core feature.
    *   **Explicit Null**: The `Value` `oneof` now includes `NullValue`, eliminating ambiguity.
    *   **Batching**: The design for future batching support has been captured in the "Future Considerations" section, which is the perfect place for it.
    *   **Security Context**: The `SecurityContext` message is now concretely defined with `principal_id` and `tenant_id`, making multi-tenancy a tangible and implementable feature from day one.

The specification is not just patched; it's holistically improved. The requirements are tighter, the IDL is more precise, and the implementation plan is clearer.

---

### Anything Else? (Final Thoughts for the Road Ahead)

The specification itself is complete. The following are not requests for changes to the spec, but rather high-level considerations for the team that begins the **implementation** of the Altar protocol.

**1. Runtime Lifecycle & Availability Notification**

*   **Consideration**: The spec perfectly covers a Runtime disconnecting gracefully (`UnregisterRuntime`). What happens when a Runtime crashes or becomes unresponsive? The Host's Health Monitoring will detect this. The question is, what happens next from a client's perspective?
*   **Implementation Thought**: A Level 2+ Host implementation should probably have a mechanism to notify active sessions that a tool provider has become unavailable. This could be a server-sent event or a status field in a session query. For Level 1, simply having the next `ToolCall` fail with a `runtime_unavailable` error is perfectly acceptable. The key is that this is an *implementation detail* of the Host, not a missing piece of the protocol itself.

**2. Tool Contract Evolution (Versioning)**

*   **Consideration**: The `ToolManifest` has a version, which is excellent for managing the entire set of contracts. What happens when a single tool contract needs to evolve? For example, adding an optional parameter to `get_weather`.
*   **Implementation Thought**: The spec is flexible enough to support multiple strategies here, and the implementers should choose one.
    *   **Strategy A (Semantic Versioning in Name)**: Create a new contract named `get_weather_v2`. This is simple and explicit.
    *   **Strategy B (Metadata Versioning)**: Add a `version` field to the `ToolContract`'s metadata map. The Host could then route to the latest compatible version.
    *   The current spec implicitly supports Strategy A, which is the simplest and safest place to start.

**3. Resource Management & Sandboxing**

*   **Consideration**: A core promise of the Host is orchestration and control. An important aspect of this is preventing a single buggy or malicious Runtime from consuming all system resources (a "noisy neighbor" problem).
*   **Implementation Thought**: This falls under the `SecurityContext` and `Authorization Engine` components. A Level 3 Host implementation could extend the `AnnounceRuntime` message to include resource limits (max memory, CPU share). The Host could then use this information to enforce cgroup/container limits or simply monitor and terminate misbehaving Runtimes. The current protocol provides the necessary hooks to build this without modification.

### Final Verdict

**The specification is finished and excellent.**

It has successfully navigated the complex trade-offs between security, flexibility, and developer experience. The foundation is exceptionally strong, and the clear compliance levels provide a pragmatic path from a simple proof-of-concept to a full-scale, secure, enterprise-wide deployment.

You have successfully designed the "MCP of interop." It's time to build it.