RCO-A2A - Regulatory Compliance Objects

Publish record (issuer)

publish_record

Idempotent

Publish a signed Regulatory Compliance Object to the partner rail (rco-a2a-cpg.ai). The ONLY write path in the suite, and it accepts only what already verifies: the record must be schema-valid RCO v1.3, its issuer must be a cpg-rail issuer active in the signed consortium registry, its verification_url must equal that issuer's registry JWKS URL, its detached JWS must verify against that JWKS, and its record_id (and any supersession) must be consistent. GSC never authors a partner record and never holds a partner private key: GSC verifies, receipts to Azure Confidential Ledger, and serves. A submitted record is never modified. Idempotent: republishing a byte-identical record returns the same receipt. Typed errors only.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`record`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`note`	No
`slot`	Yes
`ledger`	Yes
`card_url`	No
`published`	Yes
`record_id`	Yes
`idempotent`	No
`record_url`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed10 schema fields changedSep 17, 2026

changedInput schema / properties / record / $comment

Previous value: -"Record wire version stays 1.0. Cross-field checks a JSON Schema cannot express are normative in the specification and enforced by the published validator: (a) resolved_at < valid_until; (b) record_id's issuer/object/jurisdiction segments equal issuer.id, object_id and jurisdiction; (c) supersedes, when present, differs from record_id only in its trailing sequence number, which is exactly one lower; (d) GTINs are zero-padded GTIN-14 with a valid GS1 check digit; (e) host object_ids are lowercase, punycode-encoded, no trailing dot. record_id keeps its colons on the wire; a filesystem mirror replaces each colon with an underscore (CEO ruling 2026-08-29). GB is rejected as invalid_jurisdiction naming the valid set — UK is the member code (permanent GB=UK rule). Verification VERIFIES every byte of the canonical signing payload; nothing claims to reproduce signature bytes (ECDSA is randomized). v1.3 adds the optional case_study boolean and the unit rule: record-holders are keyed GTIN x jurisdiction only (NG-11 s2k)."New value: +"Record wire version stays 1.0. Cross-field checks a JSON Schema cannot express are normative in the specification and enforced by the published validator: (a) resolved_at < valid_until; (b) record_id's issuer/object/jurisdiction segments equal issuer.id, object_id and jurisdiction; (c) supersedes, when present, differs from record_id only in its trailing sequence number, which is exactly one lower; (d) GTINs are zero-padded GTIN-14 with a valid GS1 check digit; (e) host object_ids are lowercase, punycode-encoded, no trailing dot. record_id keeps its colons on the wire; a filesystem mirror replaces each colon with an underscore (CEO ruling 2026-08-29). GB is rejected as invalid_jurisdiction naming the valid set — UK is the member code (permanent GB=UK rule). Verification VERIFIES every byte of the canonical signing payload; nothing claims to reproduce signature bytes (ECDSA is randomized). v1.3 adds the optional case_study boolean and the unit rule: record-holders are keyed GTIN x jurisdiction only (NG-11 s2k). Served flat since 1.0.2 (no alternation constructs; the signal discriminator binds the state); the full contract schema is https://rco-a2a.ai/schema/v1.4/resolve_compliance.tool.json and is what the validator enforces."

removedInput schema / properties / record / allOf

Removed value: -[
-  {
-    "$comment": "The seven legal signal/state pairs.",
-    "oneOf": [
-      {
-        "properties": {
-          "signal": {
-            "const": "CPG-000"
-          },
-          "state": {
-            "const": "NOT_APPLICABLE"
-          }
-        }
-      },
-      {
-        "properties": {
-          "signal": {
-            "const": "CPG-200"
-          },
-          "state": {
-            "const": "ALLOW"
-          }
-        }
-      },
-      {
-        "properties": {
-          "signal": {
-            "const": "CPG-300"
-          },
-          "state": {
-            "const": "CONDITIONAL"
-          }
-        }
-      },
-      {
-        "properties": {
-          "signal": {
-            "const": "CPG-403"
-          },
-          "state": {
-            "const": "RESTRICT"
-          }
-        }
-      },
-      {
-        "properties": {
-          "signal": {
-            "const": "CPG-404"
-          },
-          "state": {
-            "const": "NOT_FOUND"
-          }
-        }
-      },
-      {
-        "properties": {
-          "signal": {
-            "const": "CPG-451"
-          },
-          "state": {
-            "const": "ESCALATE"
-          }
-        }
-      },
-      {
-        "properties": {
-          "signal": {
-            "const": "CPG-500"
-          },
-          "state": {
-            "const": "SYSTEM_ERROR"
-          }
-        }
-      }
-    ]
-  },
-  {
-    "$comment": "conditions: required non-empty for CPG-300, forbidden otherwise.",
-    "else": {
-      "not": {
-        "required": [
-          "conditions"
-        ]
-      }
-    },
-    "if": {
-      "properties": {
-        "signal": {
-          "const": "CPG-300"
-        }
-      }
-    },
-    "then": {
-      "properties": {
-        "conditions": {
-          "minItems": 1
-        }
-      },
-      "required": [
-        "conditions"
-      ]
-    }
-  },
-  {
-    "$comment": "CPG-404 carries eco_ref null; every other signal carries a non-null eco_ref.",
-    "else": {
-      "properties": {
-        "eco_ref": {
-          "type": "object"
-        }
-      }
-    },
-    "if": {
-      "properties": {
-        "signal": {
-          "const": "CPG-404"
-        }
-      }
-    },
-    "then": {
-      "properties": {
-        "eco_ref": {
-          "type": "null"
-        }
-      }
-    }
-  }
-]

removedInput schema / properties / record / properties / eco_ref / anyOf

Removed value: -[
-  {
-    "type": "null"
-  },
-  {
-    "properties": {
-      "hash": {
-        "pattern": "^sha256:[a-f0-9]{64}$",
-        "type": "string"
-      },
-      "url": {
-        "format": "uri",
-        "type": "string"
-      }
-    },
-    "required": [
-      "url",
-      "hash"
-    ],
-    "type": "object"
-  }
-]

addedInput schema / properties / record / properties / eco_ref / properties

Added value: +{
+  "hash": {
+    "pattern": "^sha256:[a-f0-9]{64}$",
+    "type": "string"
+  },
+  "url": {
+    "format": "uri",
+    "type": "string"
+  }
+}

addedInput schema / properties / record / properties / eco_ref / required
```
Added value: +[
+  "url",
+  "hash"
+]
```
addedInput schema / properties / record / properties / eco_ref / type
```
Added value: +[
+  "object",
+  "null"
+]
```

addedInput schema / properties / record / properties / signal / $comment

Added value: +"Discriminator. Each signal binds exactly one state: CPG-000=NOT_APPLICABLE, CPG-200=ALLOW, CPG-300=CONDITIONAL, CPG-403=RESTRICT, CPG-404=NOT_FOUND, CPG-451=ESCALATE, CPG-500=SYSTEM_ERROR. conditions: required non-empty for CPG-300, forbidden otherwise. Enforced by the validator."

removedInput schema / properties / record / properties / supersedes / anyOf

Removed value: -[
-  {
-    "type": "null"
-  },
-  {
-    "pattern": "^rco:[a-z0-9-]+:(gtin:[0-9]{14}|host:([a-z0-9]([a-z0-9-]{0,61}[a-z0-9])?\\.)+[a-z]{2,63}):([A-Z]{2}-ECO-10060|apex):[1-9][0-9]*$",
-    "type": "string"
-  }
-]

addedInput schema / properties / record / properties / supersedes / pattern

Added value: +"^rco:[a-z0-9-]+:(gtin:[0-9]{14}|host:([a-z0-9]([a-z0-9-]{0,61}[a-z0-9])?\\.)+[a-z]{2,63}):([A-Z]{2}-ECO-10060|apex):[1-9][0-9]*$"

addedInput schema / properties / record / properties / supersedes / type
```
Added value: +[
+  "string",
+  "null"
+]
```

Changed7 schema fields changedSep 17, 2026

removedInput schema / additionalProperties
```
Removed value: -false
```
removedInput schema / properties / record / additionalProperties
```
Removed value: -false
```
removedInput schema / properties / record / properties / conditions / items / additionalProperties
```
Removed value: -false
```

changedInput schema / properties / record / properties / eco_ref / anyOf

Previous value: -[
-  {
-    "type": "null"
-  },
-  {
-    "additionalProperties": false,
-    "properties": {
-      "hash": {
-        "pattern": "^sha256:[a-f0-9]{64}$",
-        "type": "string"
-      },
-      "url": {
-        "format": "uri",
-        "type": "string"
-      }
-    },
-    "required": [
-      "url",
-      "hash"
-    ],
-    "type": "object"
-  }
-]New value: +[
+  {
+    "type": "null"
+  },
+  {
+    "properties": {
+      "hash": {
+        "pattern": "^sha256:[a-f0-9]{64}$",
+        "type": "string"
+      },
+      "url": {
+        "format": "uri",
+        "type": "string"
+      }
+    },
+    "required": [
+      "url",
+      "hash"
+    ],
+    "type": "object"
+  }
+]

removedInput schema / properties / record / properties / evidence_refs / items / additionalProperties
```
Removed value: -false
```
removedInput schema / properties / record / properties / issuer / additionalProperties
```
Removed value: -false
```
removedInput schema / properties / record / properties / rule_set / additionalProperties
```
Removed value: -false
```

First observedSep 1, 2026

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare idempotentHint=true, readOnlyHint=false, and destructiveHint=false. The description adds valuable behavioral context beyond these: GSC never authors records or holds private keys, verifies and receipts to Azure Confidential Ledger, never modifies submitted records, and is idempotent with byte-identical republishing. It stops short of describing auth requirements, rate limits, or error categories, but the added context is meaningful and non-contradictory.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single dense paragraph with no filler; every sentence earns its place by adding operational or verification context. It could be more scannable with a short precondition list, but the length is justified by the complexity of the tool and the absence of schema descriptions.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complex single-parameter tool, no schema descriptions, and an existing output schema, the description covers the essential operational context: purpose, verification preconditions, non-mutation, idempotency, and the GSC security posture. It does not enumerate specific typed error names or caller credentials, but the output schema and sibling context cover the remainder reasonably.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the tool description must carry semantic weight for the single 'record' parameter. It does: it explains the record must be schema-valid RCO v1.3, issuer-active in the registry, with verification_url matching the JWKS URL, a verifying detached JWS, and consistent record_id/supersession. This meaningfully compensates for the schema's lack of property descriptions, though it does not enumerate nested field semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Publish a signed Regulatory Compliance Object to the partner rail (rco-a2a-cpg.ai).' It then explicitly distinguishes itself as 'The ONLY write path in the suite,' which differentiates it from sibling read tools like get_record and resolve_compliance. An agent can immediately recognize this as the write/publish operation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives strong usage context: it is the only write path, and it 'accepts only what already verifies,' implying this tool is for publishing a pre-verified, pre-signed record rather than for discovery or compliance evaluation. It does not explicitly name the sibling tools that should be used instead for reading or resolving, but the 'only write path' framing provides clear directional guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All RCO-A2A - Regulatory Compliance Objects tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.