Corply — Start and run your company

Record an operating event

record_operating_event

Atomically stage or promote one event occurrence's stable ID and mutable anchor fact. Use this for every fact named by an event rule; scalar writes are rejected to prevent mixed IDs/deadlines. If evidence is required, the first call returns candidate fact IDs. Bind evidence to each evidence-gated candidate, then retry with identical source and validity inputs; both facts become canonical in one transaction. Prerequisite: authenticated active company access plus every prerequisite stated above. Canonicality: invokes the shared backend action; trust the returned actual_tool_output and context_engineering instead of adding a state-recovery call. Idempotency: obey the tool-specific retry key or guarantee; if none is stated, inspect refreshed state before retrying. Confirmation boundary: no additional confirmation is needed for this read, reversible save, explicit fact/evidence record, link preparation, plan refresh, or action pre-authorized by a standing founder-configured policy.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`ruleId`	Yes	Exact event-recurring ruleId returned by resolve_company_plan.
`companyId`	No	corply_companies.id. May be omitted only when this connection has exactly one company.
`expiresAt`	No
`itemLimit`	Yes	Maximum items returned per actionable/blocked/waiting section.
`sourceRef`	Yes	Stable reference reused unchanged when promoting staged candidates.
`subjectId`	No	Required for subject-scoped event rules; omitted for company rules.
`confidence`	No
`provenance`	No
`sourceType`	Yes
`trustLevel`	No
`anchorValue`	Yes	Typed value for the rule's recurrence.anchorFact.
`effectiveTo`	No
`occurrenceId`	Yes	Stable episode identity, never a mutable date, boolean, or label.
`effectiveFrom`	No
`questionLimit`	Yes	Maximum targeted missing-fact questions returned.
`_corply_context`	No
`confirmationKind`	Yes		none
`evidenceEventIds`	No
`sourceObservedAt`	No	Required for expiring evidence-backed event facts.

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedOct 2, 2026

removedInput schema / $defs

Removed value: -{
-  "__schema0": {
-    "anyOf": [
-      {
-        "type": "string"
-      },
-      {
-        "type": "number"
-      },
-      {
-        "type": "boolean"
-      },
-      {
-        "type": "null"
-      },
-      {
-        "items": {
-          "$ref": "#/$defs/__schema0"
-        },
-        "type": "array"
-      },
-      {
-        "additionalProperties": {
-          "$ref": "#/$defs/__schema0"
-        },
-        "propertyNames": {
-          "type": "string"
-        },
-        "type": "object"
-      }
-    ]
-  },
-  "__schema1": {
-    "anyOf": [
-      {
-        "type": "string"
-      },
-      {
-        "type": "number"
-      },
-      {
-        "type": "boolean"
-      },
-      {
-        "type": "null"
-      },
-      {
-        "items": {
-          "$ref": "#/$defs/__schema1"
-        },
-        "type": "array"
-      },
-      {
-        "additionalProperties": {
-          "$ref": "#/$defs/__schema1"
-        },
-        "propertyNames": {
-          "type": "string"
-        },
-        "type": "object"
-      }
-    ]
-  }
-}

removedInput schema / properties / _corply_context / description

Removed value: -"Echo context_engineering.context_session from the prior Corply result."

removedInput schema / properties / anchorValue / $ref
```
Removed value: -"#/$defs/__schema0"
```

addedInput schema / properties / anchorValue / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "number"
+  },
+  {
+    "type": "boolean"
+  },
+  {
+    "type": "null"
+  },
+  {
+    "items": {},
+    "type": "array"
+  },
+  {
+    "additionalProperties": {},
+    "propertyNames": {
+      "type": "string"
+    },
+    "type": "object"
+  }
+]

changedInput schema / properties / companyId / description

Previous value: -"corply_companies.id. May be omitted only when the active organization has exactly one company."New value: +"corply_companies.id. May be omitted only when this connection has exactly one company."

removedInput schema / properties / provenance / additionalProperties / $ref
```
Removed value: -"#/$defs/__schema1"
```

addedInput schema / properties / provenance / additionalProperties / anyOf

Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "number"
+  },
+  {
+    "type": "boolean"
+  },
+  {
+    "type": "null"
+  },
+  {
+    "items": {},
+    "type": "array"
+  },
+  {
+    "additionalProperties": {},
+    "propertyNames": {
+      "type": "string"
+    },
+    "type": "object"
+  }
+]

Changed1 schema field changedAug 26, 2026

addedInput schema / properties / _corply_context

Added value: +{
+  "additionalProperties": false,
+  "dependentRequired": {
+    "receipt": [
+      "id"
+    ]
+  },
+  "description": "Echo context_engineering.context_session from the prior Corply result.",
+  "properties": {
+    "id": {
+      "maxLength": 200,
+      "minLength": 16,
+      "type": "string"
+    },
+    "receipt": {
+      "maxLength": 2048,
+      "minLength": 16,
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

Changed1 schema field changedJul 15, 2026

changedInput schema / properties / ruleId / description

Previous value: -"Exact event-recurring ruleId returned by inspect_operating_rule."New value: +"Exact event-recurring ruleId returned by resolve_company_plan."

AddedJul 15, 2026

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already establish this is a non-destructive write (readOnlyHint=false, destructiveHint=false, openWorldHint=false), and the description adds genuinely useful behavior: atomic transactional promotion, rejection of scalar writes, an idempotency/retry rule, a confirmation boundary, and the authenticated-company prerequisite. Some of this is generic boilerplate ('trust the returned actual_tool_output') that dilutes the signal, but the substantive disclosures go beyond the annotations.

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

Conciseness3/5

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

The core purpose and evidence workflow are front-loaded, which is good, but the text is padded with generic boilerplate sections (Canonicality, Idempotency, Confirmation boundary) whose sentences restate policy rather than tool-specific behavior. It is readable but not tight.

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?

For a complex 19-parameter mutation with no output schema, the description covers the workflow, prerequisites, idempotency, confirmation boundary, and even return behavior ('the first call returns candidate fact IDs'). It is nearly sufficient, with the main gap being parameter-level coverage rather than missing behavioral context.

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

Parameters2/5

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

Schema description coverage is only 47% across 19 parameters, so the description carries a heavy compensating burden and largely fails to meet it. It gestures at concepts ('identical source and validity inputs', 'stable ID', 'mutable anchor fact') that loosely map to sourceRef/effectiveFrom/effectiveTo, occurrenceId, and anchorValue, but it never explains the required confirmationKind, itemLimit/questionLimit, or the many optional fields left undocumented in both places.

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

Purpose4/5

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

States a specific verb (stage/promote) and resource (one event occurrence's stable ID and anchor fact) and scopes it with 'Use this for every fact named by an event rule,' which helps separate it from the sibling record_operating_fact. The jargon ('stable ID', 'mutable anchor fact') is dense but precise. It stops short of explicitly naming the sibling alternatives it differs from.

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?

Gives clear context: use it for facts named by an event rule, scalar writes are rejected, and it spells out the two-phase evidence-gated flow (first call returns candidate fact IDs, bind evidence, retry with identical source/validity inputs). What is missing is an explicit 'when not to use' or a named alternative such as record_operating_fact or record_operating_evidence.

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

All Corply — Start and run your company 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.

Record an operating event

Input Schema

Schema Changelog

TDQS

Glama MCP Gateway

Resources