Registration, approval, and activation

Registration describes a target. Review approves its configuration. Activation makes approved configuration available to a runtime. Policy then determines which callers can discover and use its tools.

Follow the boundaries in order

1. Register the server endpoint, owner, transport, route, and credential requirements.
2. Validate its declared configuration and compatibility evidence.
3. Review the submitted configuration through the approval workflow.
4. Confirm that the runtime has accepted the approved projection.
5. Test discovery and execution as the intended caller.

These are verification checkpoints, not interchangeable status labels. Use the resource’s displayed reason and the API schema for exact lifecycle state names.

Compatibility is explicit

Transport, protocol version, route class, capabilities, and security posture are separate fields. The runtime uses the resolved approved profile. It must not guess a transport from the shape of a URL or forward arbitrary requests to an unregistered address.

Changes need another check

A changed endpoint, credential relationship, or transport can alter the approved boundary. Review the new configuration and verify the resulting runtime projection instead of assuming the previous successful call still proves readiness.

Start with registering a server. For REST services, use selected OpenAPI operations.

Implementation reference

Read the source contract.