Skip to main content
Glama

Corply — Start and run your company

by io.github.corply-dev
OverviewDiscussionsAdmin

Record operating evidence

record_operating_evidence

Record a company-owned evidence artifact, then freshly resolve the plan. Evidence is not task completion by itself; attach its id when transitioning a work item. For new files, call upload_operating_evidence (or the authenticated multipart upload endpoint) and use its server-returned filePath/fileHash. Founder-uploaded documents remain claims: use submit_operating_fact_evidence to bind and queue them for operator review. Only an operator may directly promote an evidence-confirmed fact. Professional determinations require named reviewer credentials. A guidance link or model assertion is never professional evidence. 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
NameRequiredDescriptionDefault
kindYes
titleYes
coversNoExact completionEvidence labels from workItemId that this artifact proves.
factIdNoCandidate/current fact assertion this evidence substantiates. Unbound evidence cannot promote a fact.
fileHashNoFull SHA-256 of the stored bytes; Corply downloads and verifies it server-side.
filePathNoImmutable object in corply-documents under operating-evidence/<orgId>/<companyId>/. Copy mutable formation aliases through upload_operating_evidence first.
metadataNoNon-secret artifact metadata.
companyIdNocorply_companies.id. May be omitted only when this connection has exactly one company.
itemLimitYesMaximum items returned per actionable/blocked/waiting section.
workItemIdNoRequired when covers is non-empty; prevents reusing self-declared labels across occurrences.
descriptionNo
professionalNo
questionLimitYesMaximum targeted missing-fact questions returned.
_corply_contextNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • 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"
-      }
-    ]
-  }
-}
    • removedInput schema / properties / _corply_context / description
      Removed value: -"Echo context_engineering.context_session from the prior Corply result."
    • 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 / metadata / additionalProperties / $ref
      Removed value: -"#/$defs/__schema0"
    • addedInput schema / properties / metadata / additionalProperties / anyOf
      Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "number"
+  },
+  {
+    "type": "boolean"
+  },
+  {
+    "type": "null"
+  },
+  {
+    "items": {},
+    "type": "array"
+  },
+  {
+    "additionalProperties": {},
+    "propertyNames": {
+      "type": "string"
+    },
+    "type": "object"
+  }
+]
  2. Changed1 schema field changed
    • 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"
+}
  3. Added

TDQS

A4.4/5.0
Behavior4/5

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

Goes well beyond the annotations (readOnlyHint=false, destructiveHint=false) by disclosing that only an operator may promote an evidence-confirmed fact, that professional determinations need named reviewer credentials, that guidance links/model assertions never qualify as evidence, and that evidence alone is not task completion. Idempotency and canonicality clauses add retry/return-value context. Docked one point because the idempotency and canonicality language is generic boilerplate rather than tool-specific detail.

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?

Purpose and routing are front-loaded well, but the final canonicality/idempotency/confirmation-boundary paragraph is near-generic template prose ('obey the tool-specific retry key or guarantee; if none is stated, inspect refreshed state before retrying') that a reader must wade through. The block is longer than the routing value it delivers.

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 14-parameter, no-output-schema tool this is close to complete: it names the upstream upload tool, the sibling claim-binding tool, the actor restrictions, and the prerequisite. It omits what the 'freshly resolved plan' response contains, but with no output schema that gap is minor given how much else is covered.

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?

With 64% schema description coverage, the description usefully compensates: it ties filePath/fileHash to the upload flow (server-returned values), explains that a work item id must be attached for a covers binding, and flags that professional determinations require reviewer credentials (professional.*). It does not explain kind, itemLimit, or questionLimit semantics, so it is not fully compensating.

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?

Opens with a specific verb+resource ('Record a company-owned evidence artifact, then freshly resolve the plan') and immediately distinguishes the tool from upload_operating_evidence and submit_operating_fact_evidence by naming each sibling's distinct role. An agent can pick this apart from the ~120 siblings without opening the schema.

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

Usage Guidelines5/5

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

Explicit routing rules: new files go to upload_operating_evidence (or the multipart endpoint), founder-uploaded documents go to submit_operating_fact_evidence, and evidence ids are attached when transitioning a work item. Prerequisite (authenticated active company access) is stated outright, so when-to-use and when-not-to-use are both covered.

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 toolsInspect
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.

Resources