On this page
RNX code library · 5 controls
RNX-310Agentic Discovery & Identity
Read what these checks mean, why they matter and which evidence they concern. Each ID below keeps its canonical place in the RNX hierarchy.
These are free learning summaries, not full technical tests or an industry certification. Specialized checks apply only to the relevant feature. Experimental labels are preserved from the canonical source.
RNX-311 · Standardized MCP Server Architecture
RNX-311.T001
Pinned MCP version conformance
core readiness
For an implemented MCP connection, test the selected protocol version and the specific supported clauses.
Why it matters. A few working examples do not prove complete compatibility.
Illustration — fictional. An integration follows the setup rules of an older protocol rather than the version it claims to support.
When it applies. Inspected target: MCP contract fixture. Use this check only when that object or feature exists in the review scope; provider-specific checks require that provider's integration. Missing evidence remains unknown.
RNX-312 · Agent Card & Capability Manifest
RNX-312.T001
Capability advertisement accuracy
core readiness
Advertise only machine capabilities that really work.
Why it matters. A manifest should not promise tools the service has not implemented.
Illustration — fictional. A service advertises a live stream of updates but does not implement it.
When it applies. Inspected target: advertised capability. Use this check only when that object or feature exists in the review scope; provider-specific checks require that provider's integration. Missing evidence remains unknown.
RNX-314 · Deterministic Tool Authorization
RNX-314.T001
Least-privilege action scope
core readiness
Limit automated actions to the caller's allowed scope.
Why it matters. A request outside that scope must not change protected data.
Illustration — fictional. A caller allowed only to read records can change them too.
When it applies. Inspected target: scope-negative request. Use this check only when that object or feature exists in the review scope; provider-specific checks require that provider's integration. Missing evidence remains unknown.
RNX-317 · Signed Capability Manifests
RNX-317.T001
Manifest signature verification
Experimental — not an established ranking requirement
For signed manifests, distinguish an authentic version from a changed copy.
Why it matters. A signature check protects integrity, not the truth of every claim.
Illustration — fictional. A changed manifest still passes the check meant to detect tampering.
When it applies. Inspected target: signature fixture. Use this check only when that object or feature exists in the review scope; provider-specific checks require that provider's integration. Missing evidence remains unknown.
RNX-318 · Graceful Degradation Protocols
RNX-318.T001
Truthful dependency-failure response
Experimental — not an established ranking requirement
Report a failed dependency as unavailable or degraded.
Why it matters. An automated service should not invent success when an outside system fails.
Illustration — fictional. Inventory timeout produces in-stock claim.
When it applies. Inspected target: dependency failure. Use this check only when that object or feature exists in the review scope; provider-specific checks require that provider's integration. Missing evidence remains unknown.