Skip to main content
Glama

Corply — Start and run your company

by io.github.corply-dev
OverviewDiscussionsAdmin

Generate formation documents

generate_documents

Phase-aware immutable generation. Company-name search results are advisory and do not gate this action. For Delaware C-corps, before filing, status 'ready' produces the filing-stage Certificate of Incorporation. After Delaware acceptance, status 'formed' produces Bylaws, Action of Incorporator, Initial Board Consent, one stock purchase agreement per founder (RSPA for vesting; SPA for fully vested common stock), and the unsigned SS-4 using the recorded accepted date. Fully vested founders receive no 83(b) election or vesting exhibits. Personal-filing founders sign/file their election themselves; Corply generates no executed election for them. After a managed-filing founder's RSPA is fully executed, Corply automatically produces that founder's 83(b) Election from the actual stock-purchase date and executes it under the advance authorization captured in the founder's signing bundle. A canonical next step may call this tool without another founder confirmation solely to retry that automatic 83(b) preparation. Otherwise, confirm before creating immutable legal documents. Before filing, editing a generated application reopens the formation, supersedes its Certificate and collected signatures, and requires re-generation and re-signing. 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: follow the canonical nextStep—confirm when checkpoint=true; an automatic 83(b) preparation retry explicitly needs no new approval.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
formationIdYes
_corply_contextNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • removedInput schema / properties / _corply_context / description
      Removed value: -"Echo context_engineering.context_session from the prior Corply result."
  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. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations only give readOnlyHint=false, destructiveHint=false, openWorldHint=false; the description adds substantial context beyond them: immutable output, advisory-only name-search results, the edit-supersedes-Certificate consequence, automatic 83(b) execution under prior authorization, idempotency/retry-key guidance, and canonicality. It is not a full 5 only because the retry-key mechanics are deferred ('obey the tool-specific retry key') rather than specified.

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 opening line is front-loaded and the branch-by-status structure is logical, but the description is very dense and long, packing confirmation, idempotency, and canonicality rules into a single block. Much of it earns its place for a complex tool, but the size and run-on sentences reduce readability.

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, phase-aware, multi-branch generation tool with no output schema, the description covers phases, prerequisites, confirmation, idempotency, and canonicality well, and points the agent to actual_tool_output. It is incomplete only on parameter meaning, which is a genuine gap.

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 coverage is 0% and there are 2 parameters (formationId, _corply_context), yet the description never explains formationId or the context object. It references prerequisites and returned context_engineering, but adds no semantics for the actual inputs, so it fails to compensate for the coverage gap.

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?

States a specific verb+resource ('generation' of formation documents) and goes further by enumerating exactly what is produced per formation status: Certificate of Incorporation at 'ready', Bylaws/Action of Incorporator/Board Consent/SPAs/SS-4 at 'formed'. An agent can immediately tell this apart from siblings like get_my_governed_document or save_application.

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 when-to-use branching on formation status, prerequisites ('authenticated active company access'), the confirmation boundary (confirm when checkpoint=true, but no approval for automatic 83(b) retry), and a warning that editing reopens the formation and requires re-generation. When-not and alternative conditions are spelled out rather than left to inference.

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